match formats and arguments exactly

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

match formats and arguments exactly

Pascal Cuoq
Hello,

If no-one objects, I will push in a few days the following patch, which ensures that the types of arguments to printing functions correspond exactly to their formatters (%x expects an unsigned int, %s expects a pointer to character type, etc.).

Pascal

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

formatting.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Christian Jullien-3
This is a valuable check but IMHO, it should be controlled by -Wformat (as
GNU gcc) and set of false by default.
Otherwise, I suspect tcc users will have a lot a new warnings.

I'll personally definitely will adopt this flag as I do with gcc.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]]
On Behalf Of Pascal Cuoq
Sent: Friday, June 21, 2019 12:00
To: [hidden email]
Subject: [Tinycc-devel] match formats and arguments exactly

Hello,

If no-one objects, I will push in a few days the following patch, which
ensures that the types of arguments to printing functions correspond exactly
to their formatters (%x expects an unsigned int, %s expects a pointer to
character type, etc.).

Pascal


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Pascal Cuoq

> On 21 Jun 2019, at 14:56, Christian Jullien <[hidden email]> wrote:
>
> This is a valuable check but IMHO, it should be controlled by -Wformat (as
> GNU gcc) and set of false by default.
> Otherwise, I suspect tcc users will have a lot a new warnings.

I'm not implementing a new warning in TCC. I am only ensuring, by following C11 7.21.6.1:8 to the letter, that the TCC source code passes the strictest such checks that a C compiler could have, and also that a very exotic C compiler does not produce a non-functional binary when compiling TCC.

Considering the amount of code that good warnings represent, I think that a C compiler can either be tiny, or provide helpful warnings. The patches I have been sending, including the last one, only make TCC not exhibit undefined behavior, a more manageable goal that only requires small changes and do not make TCC significantly larger.

Pascal


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Christian Jullien-3

If I read you correctly, you want to protest if type does not strictly match format directive.

 

This is something even gcc does NOT ensure by default:

 

#include <stdio.h>

#include <stdlib.h>

 

int

main() {

        int i = 256;

        const char* s = "Hello";

        const void* p = s;

 

        printf("%x\n", i);

        printf("%u %s\n", i, p);

}

 

 

$ gcc -std=c11  foo.c

$ => Ok

 

Only -Wformat (or -Wall) shows a warning on the 2nd printf, printf of i (a signed) is always Ok.

 

$ gcc -std=c11 -Wall foo.c

foo.c: In function 'main':

foo.c:11:21: warning: format '%s' expects argument of type 'char *', but argument 3 has type 'const void *' [-Wformat=]

         printf("%u %s\n", i, p);                                                                   ~^                                                                              %p       

 

-----Original Message-----
From: Pascal Cuoq [mailto:[hidden email]]
Sent: Friday, June 21, 2019 15:17
To: [hidden email]; [hidden email]
Subject: Re: [Tinycc-devel] match formats and arguments exactly

 

 

> On 21 Jun 2019, at 14:56, Christian Jullien <[hidden email]> wrote:

>

> This is a valuable check but IMHO, it should be controlled by -Wformat (as

> GNU gcc) and set of false by default.

> Otherwise, I suspect tcc users will have a lot a new warnings.

 

I'm not implementing a new warning in TCC. I am only ensuring, by following C11 7.21.6.1:8 to the letter, that the TCC source code passes the strictest such checks that a C compiler could have, and also that a very exotic C compiler does not produce a non-functional binary when compiling TCC.

 

Considering the amount of code that good warnings represent, I think that a C compiler can either be tiny, or provide helpful warnings. The patches I have been sending, including the last one, only make TCC not exhibit undefined behavior, a more manageable goal that only requires small changes and do not make TCC significantly larger.

 

Pascal


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

ian

Hello,

IMHO, considering that flexibility is what I love in C programming, and that this checking should be printf job (in that case), and many other things, I agree with Christian.
Even more, still IMHO, a pointer is a pointer, no matter actually how it will be interpreted later.

Regards

-- ian ([hidden email])
-- développeur compulsif
Le 21/06/2019 à 15:33, Christian Jullien a écrit :

If I read you correctly, you want to protest if type does not strictly match format directive.

 

This is something even gcc does NOT ensure by default:

 

#include <stdio.h>

#include <stdlib.h>

 

int

main() {

        int i = 256;

        const char* s = "Hello";

        const void* p = s;

 

        printf("%x\n", i);

        printf("%u %s\n", i, p);

}

 

 

$ gcc -std=c11  foo.c

$ => Ok

 

Only -Wformat (or -Wall) shows a warning on the 2nd printf, printf of i (a signed) is always Ok.

 

$ gcc -std=c11 -Wall foo.c

foo.c: In function 'main':

foo.c:11:21: warning: format '%s' expects argument of type 'char *', but argument 3 has type 'const void *' [-Wformat=]

         printf("%u %s\n", i, p);                                                                   ~^                                                                              %p       

 

-----Original Message-----
From: Pascal Cuoq [[hidden email]]
Sent: Friday, June 21, 2019 15:17
To: [hidden email]; [hidden email]
Subject: Re: [Tinycc-devel] match formats and arguments exactly

 

 

> On 21 Jun 2019, at 14:56, Christian Jullien [hidden email] wrote:

>

> This is a valuable check but IMHO, it should be controlled by -Wformat (as

> GNU gcc) and set of false by default.

> Otherwise, I suspect tcc users will have a lot a new warnings.

 

I'm not implementing a new warning in TCC. I am only ensuring, by following C11 7.21.6.1:8 to the letter, that the TCC source code passes the strictest such checks that a C compiler could have, and also that a very exotic C compiler does not produce a non-functional binary when compiling TCC.

 

Considering the amount of code that good warnings represent, I think that a C compiler can either be tiny, or provide helpful warnings. The patches I have been sending, including the last one, only make TCC not exhibit undefined behavior, a more manageable goal that only requires small changes and do not make TCC significantly larger.

 

Pascal



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Pascal Cuoq
In reply to this post by Christian Jullien-3

On 21 Jun 2019, at 15:33, Christian Jullien <[hidden email]> wrote:

If I read you correctly, you want to protest if type does not strictly match format directive.

I'm not protesting, I'm just offering a patch (in a series of patches) that makes the TCC source code free of easily avoided undefined behavior.

I admit I'm not very interested in knowing whether GCC warns or not for the things I am fixing, because GCC neither warns for everything that's undefined nor limits its warnings to things that are undefined. The C standards are my reference, in this case, https://port70.net/~nsz/c/c11/n1570.html#7.21.6.1p8 , which says:


7.21.6.1:8

o,u,x,X
  The unsigned int argument is

  If no l length modifier is present, the argument shall be a pointer to the initial element of an array of character type.

7.21.6.1:9 

… If any argument is not the correct type for the corresponding conversion specification, the behavior is undefined.



I was asking about the patch because I have encountered developers who prefer to keep their invalid pointer arithmetic, uses of uninitialized memory and misuse of printf, in which case I don't insist.

Pascal




_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Pascal Cuoq
In reply to this post by ian

On 21 Jun 2019, at 16:10, ian <[hidden email]> wrote:

Hello,IMHO, considering that flexibility is what I love in C programming, and that this checking should be printf job (in that case),


Unfortunately, this is not how printf, or other variadic functions, work. The way they work is: the non-variadic arguments (in the case of printf, the format string) indicate what variadic arguments should be consumed with what type. If the types of the arguments actually passed do not match the types indicated by the non-variadic arguments, the behavior is undefined.

Not only printf, and other variadic functions, have no obligation to warn you if you misuse them, but on every existing platform (including the exotic platforms where a pointer is not a pointer), they actually have no way to warn you that you are misusing them.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
ian
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

ian

Hi Pascal,

I *know* that (including the no-way part).
And I *know* too that this misuse is sometimes what's expected by developers...
Anyway, I don't think it's desirable that kinds of pointers are checked.
Still my humble opinion.

-- ian ([hidden email])
-- développeur compulsif
Le 21/06/2019 à 16:47, Pascal Cuoq a écrit :

On 21 Jun 2019, at 16:10, ian <[hidden email]> wrote:

Hello,IMHO, considering that flexibility is what I love in C programming, and that this checking should be printf job (in that case),


Unfortunately, this is not how printf, or other variadic functions, work. The way they work is: the non-variadic arguments (in the case of printf, the format string) indicate what variadic arguments should be consumed with what type. If the types of the arguments actually passed do not match the types indicated by the non-variadic arguments, the behavior is undefined.

Not only printf, and other variadic functions, have no obligation to warn you if you misuse them, but on every existing platform (including the exotic platforms where a pointer is not a pointer), they actually have no way to warn you that you are misusing them.


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Pascal Cuoq

On 21 Jun 2019, at 16:54, ian <[hidden email]> wrote:

Anyway, I don't think it's desirable that kinds of pointers are checked.


Should I emphasize that I am not offering to implement a warning in TCC? If you think that GCC should not emit the warning shown by Christian, you can either not enable this GCC warning when you use GCC, or file a bug with GCC developers so that they won't warn for this  construct with -Wall, or not use GCC. But this GCC warning entered the discussion only because Christian replied without reading the patch, and it has nothing to do with the patch I sent.

Again: I do not want to warn about wrong printf arguments. I am not adding a warning about wrong printf arguments to TCC.

I hope this clears things up.

Pascal


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Christian Jullien-3
In reply to this post by ian
Don't misunderstand me, this check is a very valuable addition. For an
uncounted number of years I use any possible warnings and my code (almost)
pass with all sanitizer, splint, code analyzers ...
You should also understand that many code slowly moved from K&R to ANSI, to
C98 .. C11 and it's a pain to port from one C version to another especially
when you're not the original author.
If you always do this check, suddenly a code w.o warning you develop with
tcc will display hundreds or thousands new warnings nobody will have the
energy to fix (very likely with a ugly cast on the argument).
Rigid (or pedantic) developers, as I am, certainly would like to activate
-Wformat and fix incorrect format string. Others, will be very happy to see
no more warning than they use to have.

So I personally vote to add this check if it protest only with -Wformat. I
can also accept it exists only with -std=c11 even if it's not the gcc
behavior.

IMHO gcc compatibility (or VC++ on Windows) should be a goal for tcc. We are
many to use tcc for its fast development cycle but gcc/vc remains the only
choice for release.


From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]]
On Behalf Of ian
Sent: Friday, June 21, 2019 16:54
To: [hidden email]
Subject: Re: [Tinycc-devel] match formats and arguments exactly

Hi Pascal,
I *know* that (including the no-way part).
And I *know* too that this misuse is sometimes what's expected by
developers...
Anyway, I don't think it's desirable that kinds of pointers are checked.
Still my humble opinion.
-- ian ([hidden email])
-- développeur compulsif
Le 21/06/2019 à 16:47, Pascal Cuoq a écrit :

On 21 Jun 2019, at 16:10, ian <[hidden email]> wrote:
Hello,IMHO, considering that flexibility is what I love in C programming,
and that this checking should be printf job (in that case),

Unfortunately, this is not how printf, or other variadic functions, work.
The way they work is: the non-variadic arguments (in the case of printf, the
format string) indicate what variadic arguments should be consumed with what
type. If the types of the arguments actually passed do not match the types
indicated by the non-variadic arguments, the behavior is undefined.

Not only printf, and other variadic functions, have no obligation to warn
you if you misuse them, but on every existing platform (including the exotic
platforms where a pointer is not a pointer), they actually have no way to
warn you that you are misusing them.



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Christian Jullien-3
In reply to this post by Pascal Cuoq

Okaaaay!

 

Until now, I only have read your message not the patch you propose (sorry about that).

Now it’s clear to me that you only want to improve tcc code quality (and not how tcc displays warning form code its compile).

 

No objection then :o) – and no need to –Wformat of course.

 

Christian

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Pascal Cuoq
Sent: Friday, June 21, 2019 17:09
To: [hidden email]; [hidden email]
Subject: Re: [Tinycc-devel] match formats and arguments exactly

 

 

On 21 Jun 2019, at 16:54, ian <[hidden email]> wrote:

Anyway, I don't think it's desirable that kinds of pointers are checked.

 

Should I emphasize that I am not offering to implement a warning in TCC? If you think that GCC should not emit the warning shown by Christian, you can either not enable this GCC warning when you use GCC, or file a bug with GCC developers so that they won't warn for this  construct with -Wall, or not use GCC. But this GCC warning entered the discussion only because Christian replied without reading the patch, and it has nothing to do with the patch I sent.

 

Again: I do not want to warn about wrong printf arguments. I am not adding a warning about wrong printf arguments to TCC.

 

I hope this clears things up.

 

Pascal

 


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

C.J. Wagenius
In reply to this post by Christian Jullien-3
This patch has little to do with the general forrmating functions. Maybe the name of the patch is a bit misleading. Pascal are simply casting some values to the correct type, that are formatted in error messages. This so that no undefined behavior occurs.

Hope this sort things out.

/cjw

21 juni 2019 17:24 av [hidden email]:

> Don't misunderstand me, this check is a very valuable addition. For an
> uncounted number of years I use any possible warnings and my code (almost)
> pass with all sanitizer, splint, code analyzers ...
> You should also understand that many code slowly moved from K&R to ANSI, to
> C98 .. C11 and it's a pain to port from one C version to another especially
> when you're not the original author.
> If you always do this check, suddenly a code w.o warning you develop with
> tcc will display hundreds or thousands new warnings nobody will have the
> energy to fix (very likely with a ugly cast on the argument).
> Rigid (or pedantic) developers, as I am, certainly would like to activate
> -Wformat and fix incorrect format string. Others, will be very happy to see
> no more warning than they use to have.
>
> So I personally vote to add this check if it protest only with -Wformat. I
> can also accept it exists only with -std=c11 even if it's not the gcc
> behavior.
>
> IMHO gcc compatibility (or VC++ on Windows) should be a goal for tcc. We are
> many to use tcc for its fast development cycle but gcc/vc remains the only
> choice for release.
>
>
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]]
> On Behalf Of ian
> Sent: Friday, June 21, 2019 16:54
> To: [hidden email]
> Subject: Re: [Tinycc-devel] match formats and arguments exactly
>
> Hi Pascal,
> I *know* that (including the no-way part).
> And I *know* too that this misuse is sometimes what's expected by
> developers...
> Anyway, I don't think it's desirable that kinds of pointers are checked.
> Still my humble opinion.
> -- ian ([hidden email])
> -- développeur compulsif
> Le 21/06/2019 à 16:47, Pascal Cuoq a écrit :
>
> On 21 Jun 2019, at 16:10, ian <[hidden email]> wrote:
> Hello,IMHO, considering that flexibility is what I love in C programming,
> and that this checking should be printf job (in that case),
>
> Unfortunately, this is not how printf, or other variadic functions, work.
> The way they work is: the non-variadic arguments (in the case of printf, the
> format string) indicate what variadic arguments should be consumed with what
> type. If the types of the arguments actually passed do not match the types
> indicated by the non-variadic arguments, the behavior is undefined.
>
> Not only printf, and other variadic functions, have no obligation to warn
> you if you misuse them, but on every existing platform (including the exotic
> platforms where a pointer is not a pointer), they actually have no way to
> warn you that you are misusing them.
>
>
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Ivo van Poorten
In reply to this post by Christian Jullien-3
On Fri, 21 Jun 2019 17:24:16 +0200 "Christian Jullien"
<[hidden email]> wrote:
> IMHO gcc compatibility (or VC++ on Windows) should be a goal for tcc.
> We are many to use tcc for its fast development cycle but gcc/vc
> remains the only choice for release.

clang/llvm. gcc is on its way out IMHO. Apple uses clang extensively
for both macOS and iOS.  It's the default compiler. And the Android
Linux kernel already builds with clang and soon vanilla will, too.
There are distro's almost fully build with clang already. Seems to work
on Windows, too (not a windows user myself). Not to mention the code
quality of clang/llvm vs gcc :)

Ivo



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Vincent Lefevre-10
In reply to this post by Christian Jullien-3
On 2019-06-21 15:33:24 +0200, Christian Jullien wrote:
> If I read you correctly, you want to protest if type does not
> strictly match format directive.
>
> This is something even gcc does NOT ensure by default:
[...]

This is undefined behavior, and the compiler is not required
to complain. This can just mean that your code will silently
be compiled in an unexpected way.

[...]

>         int i = 256;
>
>         const char* s = "Hello";
>
>         const void* p = s;
>
>  
>
>         printf("%x\n", i);
>
>         printf("%u %s\n", i, p);
[...]

> Only -Wformat (or -Wall) shows a warning on the 2nd printf, printf
> of i (a signed) is always Ok.

I don't think this is correct for i as int and unsigned int are not
compatible types... even though 256 has the same representation as
int and unsigned int (I think that the C standard should have been
more flexible in such a case).

--
Vincent Lefèvre <[hidden email]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Vincent Lefevre-10
In reply to this post by Ivo van Poorten
On 2019-06-21 18:25:29 +0200, Ivo van Poorten wrote:
> clang/llvm. gcc is on its way out IMHO. Apple uses clang extensively
> for both macOS and iOS.  It's the default compiler. And the Android
> Linux kernel already builds with clang and soon vanilla will, too.
> There are distro's almost fully build with clang already. Seems to work
> on Windows, too (not a windows user myself). Not to mention the code
> quality of clang/llvm vs gcc :)

Every compiler has its own benefits. That's why tcc still exists
in particular. :)

One thing GCC supports but not Clang is nested functions:

  https://bugs.llvm.org/show_bug.cgi?id=6378

FYI, this is used by GNU MPFR for (optional) logging support, and
there seems to be no way to do that in standard C.

--
Vincent Lefèvre <[hidden email]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Larry Doolittle
Friends -

On Fri, Jun 21, 2019 at 07:15:11PM +0200, Vincent Lefevre wrote:
> On 2019-06-21 18:25:29 +0200, Ivo van Poorten wrote:
> > clang/llvm. gcc is on its way out IMHO. Apple uses clang [...]

Troll alert.  :-)

> Every compiler has its own benefits. That's why tcc still exists
> in particular. :)

Right.  Wake me when clang can target MSP430 and microblaze.

Adding RISC-V support to tcc would be _extremely_ interesting.
Sorry about the armchair-quarterbacking; I can't offer any time
for that project at the moment.

   - Larry

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Michael Matz-4
In reply to this post by Pascal Cuoq
Hi,

On Fri, 21 Jun 2019, Pascal Cuoq wrote:

> If no-one objects, I will push in a few days the following patch,

I don't object, but have a request: can you explore if changing the type
of the respective variable, instead of adding casts, is equivalent?
Especially the changes in parse_escape_string look as if that's possible.
(I consider such type change only better than casts, if the former doesn't
cause further casts elsewhere, of course).


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Vincent Lefevre-10
On 2019-06-22 01:07:17 +0200, Michael Matz wrote:
> On Fri, 21 Jun 2019, Pascal Cuoq wrote:
> > If no-one objects, I will push in a few days the following patch,
>
> I don't object, but have a request: can you explore if changing the type of
> the respective variable, instead of adding casts, is equivalent? Especially
> the changes in parse_escape_string look as if that's possible.
> (I consider such type change only better than casts, if the former doesn't
> cause further casts elsewhere, of course).

Changing signed integers to unsigned just to avoid casts for
printf-like functions is a bad idea. The reason is that in
some expressions, using unsigned types can silently modify
the value of a signed type when implicitly converted to
unsigned. This is very ugly. FYI, we had bugs like that in
GNU MPFR, and that's why we changed the precision type to
a signed integer type, even though its value is always
positive.

--
Vincent Lefèvre <[hidden email]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Michael Matz-4
Hi,

On Sat, 22 Jun 2019, Vincent Lefevre wrote:

>>
>> I don't object, but have a request: can you explore if changing the type of
>> the respective variable, instead of adding casts, is equivalent? Especially
>> the changes in parse_escape_string look as if that's possible.
>> (I consider such type change only better than casts, if the former doesn't
>> cause further casts elsewhere, of course).
>
> Changing signed integers to unsigned just to avoid casts for
> printf-like functions is a bad idea. The reason is that in
> some expressions, using unsigned types can silently modify
> the value of a signed type when implicitly converted to
> unsigned.

Sure.  Which is why I said "if [changing the type] ... is equivalent".  If
it causes above issues it isn't equivalent.


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: match formats and arguments exactly

Vincent Lefevre-10
On 2019-06-22 20:34:35 +0200, Michael Matz wrote:

> Hi,
>
> On Sat, 22 Jun 2019, Vincent Lefevre wrote:
>
> > > I don't object, but have a request: can you explore if changing
> > > the type of the respective variable, instead of adding casts, is
> > > equivalent? Especially the changes in parse_escape_string look
> > > as if that's possible. (I consider such type change only better
> > > than casts, if the former doesn't cause further casts elsewhere,
> > > of course).
> >
> > Changing signed integers to unsigned just to avoid casts for
> > printf-like functions is a bad idea. The reason is that in
> > some expressions, using unsigned types can silently modify
> > the value of a signed type when implicitly converted to
> > unsigned.
>
> Sure.  Which is why I said "if [changing the type] ... is equivalent".  If
> it causes above issues it isn't equivalent.

Yes, but it can be equivalent now, but the unsigned version could
trigger bug later, when new code is added.

In general, I now tend to use signed integers for integers on which
standard integer arithmetic will be done (even when the value will
always be non-negative), except when the range is not sufficient
and the unsigned version would be sufficient (for instance, an
unsigned int can represent the sum of two non-negative int), but
these are quite particular cases. And I use unsigned integers when
they are intended for bitwise operations or modular arithmetic.

Even if I use printf with %x, this has no effect on the above
decision.

--
Vincent Lefèvre <[hidden email]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel