Вопрос ламерский до безобразия, но делать ничего, придется задавать... В C великое множество констант определены как 0L. Чем они отличаются от 0, неясно. Выводил в MessageBox'e, все одно - 0L==0, тогда какого оно надо?

L - означает LONG, другой размер переменной. Отличий от 0L и нет. С нулем только математики выпендирваются, решают, положительный он там, или отрицательный. Программам и нам по фигу.

Все равно не получается :-(. Если long переменной, инициированной FFFFFFFF, присвоить 0 и 0L, результат один, а насколько я вас понял, должно быть FFFF0000

Все равно не получается :-(. Если long переменной, инициированной FFFFFFFF, присвоить 0 и 0L, результат один, а насколько я вас понял, должно быть FFFF0000

Чего? Пардон, видимо я не понял. Если переменной что-то присваивается, то предыдущее значение ТЕРЯЕТСЯ!
Пример:

#include "stdio.h"

int main(void)
{
__int64 z = 0x1234567812345678;

printf ("%I64x\n", z);
z = 0L;
printf ("%I64d\n", z);

}


Теперь ассемблерный код, который соответствует части z = 0L;

.text:00411A78 mov eax, [ebp+z]
.text:00411A7B cdq
.text:00411A7C mov [ebp+ia64_1], eax
.text:00411A7F mov [ebp+ia64_2], edx

Это же основополагающий принцип! Присваивается что-то новое - старое затирается!

Ага, это у меня крыша едет. Никогда не думал, что у нуля есть размерность - это ж надо: обычный нуль и длинный нуль!

Между прочим, в MASM32 тоже используется 0L. В windows.inc определяются две константы:
SQL_SCROLL_FORWARD_ONLY equ 0L
DEF_MIN_PWAGE equ 0L
Что бы это значило?..

А у Iczelionа в ODBC туториале 0L есмь баг, который, видно мешает-таки жить, и его рекомендуют убить :
SQL_NULL_HANDLE equ 0L -> SQL_NULL_HANDLE equ 0. Значит, разные вещи...

push 0L
mov eax,0L
mov ax,0L
. . .

MASM32 всегда выдаёт ошибку, как будто он вообще не понимает 0L. Но ведь в windows.inc есть константы с L: 0L, 1L, 2L и т.д. Кто-нибудь может прояснить ситуацию?

Borland C при замене int a=0 на int a=0L поменял байт в PEзаголовке, навтыкал несколько nop'ов вместо нескольких jbe, заменил mov на popf(!), чем поверг в недоумение всех присутствующих, работа проги не изменилась - по-прежнему в 0 обращается только a, невзирая на размер, соседние байты остаются нетронутыми.
Quantum
>MASM32 всегда выдаёт ошибку, как будто он вообще не понимает 0L.
Я не знаю, где юзается SQL_SCROLL_FORWARD_ONLY, но кроме resource.inc 0L нигде нету,(если забыть про SQL...) , а с ним MASM непосредственно дела не имеет. Имеет rc, он наверное, понимает, а ml-нет.

[ Quantum: MASM32 всегда выдаёт ошибку, как будто он вообще не понимает 0L. Но ведь в windows.inc есть константы с L: 0L, 1L, 2L и т.д. Кто-нибудь может прояснить ситуацию? ]

Думаю, что я могу. Это однозначно баг. Масм не понимает суффикса L. Произошел он из-за того, что windows.inc частично делался вручную. Скорее всего, либо Iczelion, либо hutch просто перетащил определения SQL_XXX из хидера и вручную их перелопатил. Их там довольно много, так что про некоторые просто забыл. А поскольку они никому не нужны, то так там и сидят.

На http://board.win32asmcommunity.net/ есть ветка "Include file additions" в разделе по MASM32.
И у hutch'а на новом http://www.masmforum.com/ тоже, наверное, что-то подобное есть.
Можно смело постить туда как баг.

Поскольку мне самому приходится заниматься подобной хренью делая инклуды к KmdKit, могу сказать, что это адская работа - вручную переопределять из хидеров в синтаксис понятный масму. Так что ошибки тут весьма вероятны.

Four-F
Это однозначно баг.
Спасибо. Теперь всё ясно.

This 'L' came from very old "C" - when function prototypes were not considered as needed at all. When you want to pass a zero as 'long' and when you pass zero as an 'int' - in 16-bit world the stack will be damaged.

fseek (f, 0, SEEK_SET);

fseek (f, 0L, SEEK_SET);

The different code will be generated for these two seemingly SAME function calls
if no prototype for fseek() was found.

Of course, since, that time it was used in a zillion programs just by inertia of a human mind.

AsmGuru62
It became even more confusing when using NULL instead of 0 or 0L as 16/32-bit pointers.

С нулем только математики выпендирваются, решают, положительный он там, или отрицательный. Программам и нам по фигу.

Да? А сопроцессору? ;)