weiss / c99-snprintf Goto Github PK

View Code? Open in Web Editor NEW

67.0 67.0 18.0 86 KB

Portable implementation of snprintf(3), vsnprintf(3), asprintf(3), and vasprintf(3)

Home Page: http://www.jhweiss.de/software/snprintf.html

License: Other

Shell 2.23% C 83.54% Makefile 0.30% M4 13.93%

c99-snprintf's People

Contributors

Stargazers

Watchers

Forkers

liangyaozhan passily allandoensen ditupao sjones204g stangelandcl ctarbide lxj199610 xlobito liuangang zfields changes729 tmolitor-stud-tu wolf3s tedlee1024 lwjjhy zero-tang

c99-snprintf's Issues

MSVC 64-bit warning C4267

Visual Studio 2010 prints the C4267 conversion warnings on warning level /W3

snprintf.c(723): warning C4267: '=': Konvertierung von 'size_t' nach 'long', Datenverlust möglich
snprintf.c(768): warning C4267: '=': Konvertierung von 'size_t' nach 'long', Datenverlust möglich
snprintf.c(858): warning C4267: '=': Konvertierung von 'size_t' nach 'char', Datenverlust möglich
snprintf.c(862): warning C4267: '=': Konvertierung von 'size_t' nach 'short', Datenverlust möglich
snprintf.c(866): warning C4267: '=': Konvertierung von 'size_t' nach 'long', Datenverlust möglich
snprintf.c(870): warning C4267: '=': Konvertierung von 'size_t' nach 'long', Datenverlust möglich
snprintf.c(885): warning C4267: '=': Konvertierung von 'size_t' nach 'long', Datenverlust möglich
snprintf.c(889): warning C4267: '=': Konvertierung von 'size_t' nach 'long', Datenverlust möglich
snprintf.c(893): warning C4267: '=': Konvertierung von 'size_t' nach 'int', Datenverlust möglich

There has not been any new release since v1.1 from 2008. Is there any chance to have a new released version to get the changes from 2014 also in downstream repos, that still depend on v1.1? Thanks a lot?

[IMPROVEMENT] `mypow10` parameters or result should be checked to guard against overflow

Is there a known upper and lower bounds of the exponent, or a LDOUBLE_MAX variable or equivalent (maybe DBL_MAX)? If so, then we could protect against overflow.

The cast() function test against INTMAX_MAX for this very reason.

Static analysis: Overflowed return value

Coverity Scan reports an Overflowed return value from function myround.

static UINTMAX_T
myround(LDOUBLE value)
{
    UINTMAX_T intpart = cast(value);

//1. Condition (value -= intpart) < 0.5, taking false branch.
//2. overflow: Add operation overflows on operands intpart and 1UL.
//CID 59973 (#1 of 1): Overflowed return value (INTEGER_OVERFLOW)
//3. overflow_sink: Overflowed or truncated value (or a value computed from an overflowed or truncated value) ((value -= intpart) < 0.5) ? intpart : (intpart + 1UL) used as return value.
    return ((value -= intpart) < 0.5) ? intpart : intpart + 1;
}

MSVC 64-bit warning C4244

Visual Studio 2010 prints the C4244 conversion warnings on warning level /W3

snprintf.c(1184): warning C4244: '=': Konvertierung von 'long double' in 'unsigned long', möglicher Datenverlust
snprintf.c(1436): warning C4244: '=': Konvertierung von 'long double' in 'unsigned long', möglicher Datenverlust

Requires floating point excess precision on x86 with gcc

It turns out that the tests fail on linux on Intel if you add the following code:

void 
set_fpu (unsigned int mode)
{
  asm ("fldcw %0" : : "m" (*&mode));
}

and then

set_fpu(x27f);

at the start of main. This (according to https://www.linuxtopia.org/online_books/an_introduction_to_gcc/gccintro_70.html ) sets excess precision to be disabled. This makes it compatible with other platforms that do not support excess precision.

Indeed, the results that I then get from x86 compare to those that I get from a microcontroller platform.

The failed tests seem to indicate that the system sprintf is doing something different. The worst cases appear to be with very small exponents. For example:

Results don't match, format string: %.16e
         sprintf(3): [1.6784992078596053e-265] (23)
        snprintf(3): [1.6784992078596017e-265] (23)
Results don't match, format string: %.16e
         sprintf(3): [1.6784992078596089e-265] (23)
        snprintf(3): [1.6784992078596053e-265] (23)

I am a bit puzzled by the fact that the x86 code is using long double and the microcontroller platform is not.

Missing call of VA_START

As reported by modelica/ModelicaStandardLibrary#2626, is

VA_START(ap, format);

missing before the call of VA_COPY in rpl_vasprintf?

c99-snprintf/snprintf.c

Lines 1492 to 1494 in 27b59ac

    
           VA_COPY(aq, ap); 
        
           len = vsnprintf(NULL, 0, format, aq); 
        
           VA_END_COPY(aq);

weiss / c99-snprintf Goto Github PK

c99-snprintf's People

Contributors

Stargazers

Watchers

Forkers

c99-snprintf's Issues

MSVC 64-bit warning C4267

New release?

[IMPROVEMENT] `mypow10` parameters or result should be checked to guard against overflow

Static analysis: Overflowed return value

MSVC 64-bit warning C4244

Requires floating point excess precision on x86 with gcc

Missing call of VA_START

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	VA_COPY(aq, ap);
	len = vsnprintf(NULL, 0, format, aq);
	VA_END_COPY(aq);