Historically the identifiers that interpreted scifi text into integer were treating 'd' the same as 'e'. However in .bf mode they are not:

//echo -a $int(1.23e2) $int(1.23d2) vs %null.bf $int(1.23e2) $int(1.23d2)

result: 123 123 vs 123 1

I have no opinion on whether $int $abs etc should be fully compatible with .smallfloat mode, or should not see this notation in .bf mode at all. This is the only place I've ever seen where 'd' was synonymous with 'e' when interpreting notation.

Thanks for your bug report. This conversion is handled by the basic atof() CRT call which converts text to a float and is used throughout mIRC. On the atof() page, Microsoft says that support for 'd' and 'D' is non-standard and it looks like it was removed in later versions of the CRT. mIRC is currently compiled with Visual C++ 2008. I could probably add support for 'd' and 'D' to MAPM to make it work in the same way as non-bigfloat.

Just to be clear, I was referring to 'd' support for the existing identifiers when they handle the notation. For reasons I describe in my other post, I don't think it's a good idea for the new integer-only identifiers to try to support the approximation of this notation, since the approximations of 1.23e2 style of fractions can contain whatever rounding error comes from the source, which wouldn't be from mIRC because I'm not aware of mIRC itself creating this notation