[PATCH] [Bug 215844] scanf.3: Clarify ll and L modifiers

[Alejandro Colomar via Gcc]

Relevant documents:

POSIX:


glibc:


ISO C2x:


Still, from the documentation linked above, it seems to me that
"%Ln" is supported as a glibc extension, and doesn't fall into
"either no effect or undefined behavior" as says the GCC warning
shown in the bugzilla report.  I didn't modify the documentation
regarding %n, and recommend investigating a possible GCC bug.

Reported-by: Avinash Sonawane 
Link: bugzilla 
Cc: glibc 
Cc: GCC 
Signed-off-by: Alejandro Colomar 
---
 man3/scanf.3 | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/man3/scanf.3 b/man3/scanf.3
index 55058f3d2..199c8a19a 100644
--- a/man3/scanf.3
+++ b/man3/scanf.3
@@ -308,10 +308,6 @@ and the next pointer is a pointer to
 .I double
 (rather than
 .IR float ).
-Specifying two
-.B l
-characters is equivalent to
-.BR L .
 If used with
 .B %c
 or
@@ -320,12 +316,33 @@ the corresponding parameter is considered
 as a pointer to a wide character or wide-character string respectively.
 .\" This use of l was introduced in Amendment 1 to ISO C90.
 .TP
+.B ll
+(ell-ell)
+Indicates that the conversion will be one of
+.BR b ,
+.BR d ,
+.BR i ,
+.BR o ,
+.BR u ,
+.BR x ,
+.BR X ,
+or
+.B n
+and the next pointer is a pointer to a
+.I long long
+or
+.I unsigned long long
+(rather than
+.IR int ).
+.TP
 .B L
 Indicates that the conversion will be either
 \fBe\fP, \fBf\fP, or \fBg\fP
 and the next pointer is a pointer to
 .I "long double"
-or the conversion will be
+or
+(as a GNU extension)
+the conversion will be
 \fBd\fP, \fBi\fP, \fBo\fP, \fBu\fP, or \fBx\fP
 and the next pointer is a pointer to
 .IR "long long" .
@@ -683,17 +700,17 @@ floating-point conversion specifier (and is unaffected by
 etc.).
 .SH BUGS
 All functions are fully C89 conformant, but provide the
-additional specifiers
+additional modifiers
 .B q
 and
 .B a
 as well as an additional behavior of the
 .B L
 and
-.B l
-specifiers.
+.B ll
+modifiers.
 The latter may be considered to be a bug, as it changes the
-behavior of specifiers defined in C89.
+behavior of modifiers defined in C89.
 .PP
 Some combinations of the type modifiers and conversion
 specifiers defined by ANSI C do not make sense
-- 
2.30.2

Re: GSoC thoughts on C++ static analyzer support

[David Malcolm via Gcc]

On Fri, 2022-04-15 at 22:27 +0300, Φώτης Βαλασιάδης via Gcc wrote:
> Hello all,

Hi!

> 
> I am interested in said project, and I'd like to ask.
> 
> Is said project limited to providing static analysis for heap
> allocations
> and file handles?  To be clear I am asking whether or not there are
> goals
> beyond these two.
> 
> This pattern could pretty much be used for all resource-like objects
> such
> as sockets, mutexes et cetera and point is that said problems in C++
> are
> already tackled by using RAII
> . Now I understand
> that
> RAII isn't always an option nor does it solve all problems (for
> example,
> dangling references) so I am still fascinated by all of it and would
> like
> to share my thoughts.
> 
> C++11 mutexes(locks, and generally speaking all thread header
> facilities)
> could really use a static analyzer. Not only for the standard lock(),
> unlock() checks but also for "enforcing" lock ordering and other
> important
> guidelines. Read Anthony William's "Concurrency in Action" a while ago
> and
> honestly if I had a compiler that performed all those checks he
> describes
> in the book for me, which half of them I don't even remember anymore,
> THAT
> would be something else.
> 
> Now I understand that this might be really complicated for a GSoC
> project,
> but food for thought. Looking forward to hearing your thoughts on this.

This sounds fascinating, but unfortunately, the analyzer doesn't fully
support all of C++ yet, and so there's a lot of work to be done before
such a project could be attempted; some of that could make for a GSoC
project.

FWIW, there's a tracker bug for C++ support in the analyzer here:
  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110
and some of those things (e.g. exception-handling) are challenging.

In addition to those specific things, before we can really say that we
"support C++" I think there would also need to be a lot of simply using
the analyzer on C++ codebases to see what happens (including using it
on GCC's code itself) - the "unknown unknowns", as it were.

BTW, I'm about to go on a week-long trip, and will be away from my
computer during that time, so I probably won't be able to send further
emails before the application deadline.

Hope this is helpful
Dave

Re: GSoC proposal for extending static analyzer

[David Malcolm via Gcc]

On Fri, 2022-04-15 at 22:36 +0530, Mir Immad wrote:
> I've updated the link on the repo --  
> https://mirimmad.github.io/zeta-lang.
> 
> > You don't give many specifics in your personal decription.  One thing
> > I'm not seeing is a sense of how proficient you are in various
> > programming languages.  In particular, how is your C and C++?  How
> > familiar are you with the debugger?  Looking at your github, you seem
> > to have relevant experience in compilers, which is great, but all
> > your
> > code appears to be with "managed" languages such as Ruby, Java, and
> > Python  [and Zeta :)].
> 
>  I'm pretty comfortable with both C and C++ and manual mem management .
> Unfortunately, I don't have any project in C/C++ to show. Maybe I can
> use
> the time before May 20 to write something in cpp?

Perhaps write some low-level code in C and/or C++ that uses file-
descriptors?  That would help you gain familiarity with both C/C++, and
with the problem domain.  (in terms of what does good code look like,
and also, what are the ways in which a programmer can make mistakes
when using a particular API).


> About the debugger, I'm okay-ish with it. In fact, it was due to the
> debugger (and your blog on it) that I was initially able to walk
> through
> the codebase.

(nods)

> 
> 
> > That said, I got
> > the sense from your previous emails that you're not very familiar
> > with
> > the APIs, and that you chose them because that was the suggestion I
> > had
> > made on the wiki page.
> 
> thats right.
> 
> 
> >  Obviously it's something you can learn on the
> >  way, but it would be better to accurately identify which areas
> > you're
> > going need to learn along the way, and the timetable and scope should
> > reflect that.
> 
> If I understand the statement correctly; currently I'm thinking of
> extending the support for open() (for creating the fd), write/read (for
> working on the fd) and close(). This is quite analogous to what we have
> in
> sm-file. Please let me know how do you want the analyzer to be extended
> and
> if you expect support for any other FD APIs  too as I understand there
> are
> many other APIs for creating and working wiith FDs?
> 
> Thank you.

There are a lot of them; see e.g.:
  https://en.wikipedia.org/wiki/File_descriptor
Perhaps it's worth considering implementing some kind of attribute for
function-decls to specify what their behavior is with regards to file
descriptors, rather than hardcoding the expected behaviors
individually?  (not sure, perhaps one part of the project will be to
catalog the different expected preconditions and behaviors of API
entrypoints that work with file descriptors, in that I expect that they
will fall into patterns).

BTW, I'm about to go on a week-long trip, and will be away from the
computer during that time, so I probably won't be able to reply further
before the application deadline.

Hope this is helpful
Dave

> 
> 
> 
> On Fri, Apr 15, 2022 at 9:35 PM David Malcolm 
> wrote:
> 
> > On Fri, 2022-04-15 at 19:58 +0530, Mir Immad wrote:
> > > I've submitted a proposal for extending the static analyzer to
> > > support
> > > posix fd APIs on GSoC website. Here is the Google docs link (gdocs
> > > <
> > > 
> > https://docs.google.com/document/d/188zxPUsuYcF-uGVYL_G1s2RVtHhJSZeQ4sha40H7374/edit?usp=sharing
> > > > ).
> > > 
> > > 
> > > Please take a look and let me know what you think.
> > > 
> > > Thank you.
> > 
> > Thanks.
> > 
> > FWIW, I'm getting an error when trying the URL given in your github
> > repo: http://mirimmad.me/
> > but https://mirimmad.github.io/ seems to work  - but it's almost
> > empty.
> > 
> > You don't give many specifics in your personal decription.  One thing
> > I'm not seeing is a sense of how proficient you are in various
> > programming languages.  In particular, how is your C and C++?  How
> > familiar are you with the debugger?  Looking at your github, you seem
> > to have relevant experience in compilers, which is great, but all
> > your
> > code appears to be with "managed" languages such as Ruby, Java, and
> > Python  [and Zeta :)].
> > 
> > Also, the proposal is to extend the analyzer to cover a specific
> > domain: various POSIX APIs.  Can you please give a sense of your
> > level
> > of expertise with these APIs?  I was pleased at your initiative in
> > trying to reuse the existing code to work with them.  That said, I
> > got
> > the sense from your previous emails that you're not very familiar
> > with
> > the APIs, and that you chose them because that was the suggestion I
> > had
> > made on the wiki page.  Obviously it's something you can learn on the
> > way, but it would be better to accurately identify which areas you're
> > going need to learn along the way, and the timetable and scope should
> > reflect that.
> > 
> > Hope this is constructive
> > Dave
> > 
> > 
> >