unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* fix the sscanf usage in etags
@ 2006-08-07  3:38 Masatake YAMATO
  2006-08-08  9:35 ` Jan Djärv
  2006-08-09  0:06 ` Kevin Ryde
  0 siblings, 2 replies; 9+ messages in thread
From: Masatake YAMATO @ 2006-08-07  3:38 UTC (permalink / raw


Could someone install this patch?

I have some troubles in my cvs settings.
Thanks in advance.
 
2006-08-07  Masatake YAMATO  <jet@gyve.org>

	* etags.c (readline): expect sscanf returns 2, 
	not 1.

--- orig/lib-src/etags.c
+++ mod/lib-src/etags.c
@@ -6296,7 +6296,7 @@
 	  int start, lno;
 
 	  if (DEBUG) start = 0;	/* shut up the compiler */
-	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 1)
+	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 2)
 	    {
 	      char *endp = lbp->buffer + start;

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-07  3:38 fix the sscanf usage in etags Masatake YAMATO
@ 2006-08-08  9:35 ` Jan Djärv
  2006-08-09  0:06 ` Kevin Ryde
  1 sibling, 0 replies; 9+ messages in thread
From: Jan Djärv @ 2006-08-08  9:35 UTC (permalink / raw
  Cc: emacs-devel



Masatake YAMATO skrev:
> Could someone install this patch?
> 

Done.

	Jan D.

> I have some troubles in my cvs settings.
> Thanks in advance.
>  
> 2006-08-07  Masatake YAMATO  <jet@gyve.org>
> 
> 	* etags.c (readline): expect sscanf returns 2, 
> 	not 1.
> 
> --- orig/lib-src/etags.c
> +++ mod/lib-src/etags.c
> @@ -6296,7 +6296,7 @@
>  	  int start, lno;
>  
>  	  if (DEBUG) start = 0;	/* shut up the compiler */
> -	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 1)
> +	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 2)
>  	    {
>  	      char *endp = lbp->buffer + start;
>  
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-07  3:38 fix the sscanf usage in etags Masatake YAMATO
  2006-08-08  9:35 ` Jan Djärv
@ 2006-08-09  0:06 ` Kevin Ryde
  2006-08-09  6:57   ` Jan Djärv
  1 sibling, 1 reply; 9+ messages in thread
From: Kevin Ryde @ 2006-08-09  0:06 UTC (permalink / raw


Masatake YAMATO <jet@gyve.org> writes:
>
> -	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 1)
> +	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 2)

I think that's wrong, I believe %n is not included in the return
count.  Eg. in the current glibc, and in the posix spec (under "n"),

    http://www.opengroup.org/onlinepubs/007904975/functions/scanf.html

It does look like there's a problem with degenerate input having
"start" used uninitialized though.  Eg. say

	#line 00000000000000000000000000000

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-09  0:06 ` Kevin Ryde
@ 2006-08-09  6:57   ` Jan Djärv
  2006-08-09  7:57     ` Masatake YAMATO
  2006-08-10  0:15     ` Kevin Ryde
  0 siblings, 2 replies; 9+ messages in thread
From: Jan Djärv @ 2006-08-09  6:57 UTC (permalink / raw
  Cc: emacs-devel



Kevin Ryde skrev:
> Masatake YAMATO <jet@gyve.org> writes:
>> -	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 1)
>> +	  if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 2)
> 
> I think that's wrong, I believe %n is not included in the return
> count.  Eg. in the current glibc, and in the posix spec (under "n"),
> 
>     http://www.opengroup.org/onlinepubs/007904975/functions/scanf.html
> 

The man page on GNU/Linux says:
               The C standard says: "Execution of  a  %n  directive
               does  not increment the assignment count returned at the comple-
               tion of execution" but the Corrigendum seems to contradict this.
               Probably it is wise not to make any assumptions on the effect of
               %n conversions on the return value.

So I guess we safely can test for >= 1 instead for those implementations that 
do return 2.  I've checked in that change.

> It does look like there's a problem with degenerate input having
> "start" used uninitialized though.  Eg. say
> 
> 	#line 00000000000000000000000000000

We can switch places between \" and %n and check for ":

	  if (sscanf (lbp->buffer, "#line %d %n\"", &lno, &start) >= 1
	      && lbp->buffer[start] == '"')
	    {
	      char *endp = lbp->buffer + ++start;

	Jan D.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-09  6:57   ` Jan Djärv
@ 2006-08-09  7:57     ` Masatake YAMATO
  2006-08-09 13:20       ` Jan Djärv
  2006-08-10  0:15     ` Kevin Ryde
  1 sibling, 1 reply; 9+ messages in thread
From: Masatake YAMATO @ 2006-08-09  7:57 UTC (permalink / raw
  Cc: user42, emacs-devel

This is the file what I got trouble without my patch.

boost_1_33_1/libs/wave/test/testwave/testfiles/t_6_062.cpp:
/*=============================================================================
    Boost.Wave: A Standard compliant C++ preprocessor library
    http://www.boost.org/

    Copyright (c) 2001-2005 Hartmut Kaiser. Distributed under the Boost
    Software License, Version 1.0. (See accompanying file
    LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

    The tests included in this file were initially taken from the mcpp V2.5
    preprocessor validation suite and were modified to fit into the Boost.Wave 
    unit test requirements.
    The original files of the mcpp preprocessor are distributed under the 
    license reproduced at the end of this file.
=============================================================================*/

// Tests error reporting: #line error.

// 7.4: string literal in #line directive shall be a character string
//      literal.
//E t_6_062.cpp(21): warning: ill formed #line directive: 123 L"wide"
#line 123 L"wide"

/*-
 * Copyright (c) 1998, 2002-2005 Kiyoshi Matsui <kmatsui@t3.rim.or.jp>
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-09  7:57     ` Masatake YAMATO
@ 2006-08-09 13:20       ` Jan Djärv
  2006-08-09 14:10         ` Masatake YAMATO
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Djärv @ 2006-08-09 13:20 UTC (permalink / raw
  Cc: user42, emacs-devel



Masatake YAMATO skrev:
> This is the file what I got trouble without my patch.
> 

...

> // 7.4: string literal in #line directive shall be a character string
> //      literal.
> //E t_6_062.cpp(21): warning: ill formed #line directive: 123 L"wide"
> #line 123 L"wide"
> 

I don't know if etags supports wide characters at all.  A line directive like 
that is not allowed by ANSI-C as the comment says.

	Jan D.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-09 13:20       ` Jan Djärv
@ 2006-08-09 14:10         ` Masatake YAMATO
  0 siblings, 0 replies; 9+ messages in thread
From: Masatake YAMATO @ 2006-08-09 14:10 UTC (permalink / raw
  Cc: user42, emacs-devel

> Masatake YAMATO skrev:
> > This is the file what I got trouble without my patch.
> > 
> 
> ...
> 
> > // 7.4: string literal in #line directive shall be a character string
> > //      literal.
> > //E t_6_062.cpp(21): warning: ill formed #line directive: 123 L"wide"
> > #line 123 L"wide"
> > 
> 
> I don't know if etags supports wide characters at all.  A line directive like 
> that is not allowed by ANSI-C as the comment says.

I see. In this case, etags should ignore the line.
The problem I found was that etags crashed when `#line 123 L"wide"' was given
as input. If the crashing can be suppressed, it is enough.

> We can switch places between \" and %n and check for ":
> 
> 	  if (sscanf (lbp->buffer, "#line %d %n\"", &lno, &start) >= 1
> 	      && lbp->buffer[start] == '"')
> 	    {
> 	      char *endp = lbp->buffer + ++start;

This works fine.
I tested with:

const char * buffer = "#line 123                                      L\"wide\"";
const char * buffer = "#line 123 L\"wide\"";
const char * buffer = "#line 123L\"wide\"";

Masatake YAMATO

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-09  6:57   ` Jan Djärv
  2006-08-09  7:57     ` Masatake YAMATO
@ 2006-08-10  0:15     ` Kevin Ryde
  2006-08-10  6:47       ` Jan Djärv
  1 sibling, 1 reply; 9+ messages in thread
From: Kevin Ryde @ 2006-08-10  0:15 UTC (permalink / raw


Masatake YAMATO <jet@gyve.org> writes:
>
> The problem I found was that etags crashed when `#line 123 L"wide"' was given
> as input. If the crashing can be suppressed, it is enough.

That's the only bad case, you don't have some strange libc that
incorrectly counts %n?

Jan Djärv <jan.h.d@swipnet.se> writes:
>
> 	  if (sscanf (lbp->buffer, "#line %d %n\"", &lno, &start) >= 1
> 	      && lbp->buffer[start] == '"')

I think that still uses start uninitialized on say "#line 123 ".  I'd
suggest (untested) something like

	start = -1;
	if (sscanf (lbp->buffer, "#line %d \"%n", &lno, &start) == 1
	    && start != -1)
	  ...

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: fix the sscanf usage in etags
  2006-08-10  0:15     ` Kevin Ryde
@ 2006-08-10  6:47       ` Jan Djärv
  0 siblings, 0 replies; 9+ messages in thread
From: Jan Djärv @ 2006-08-10  6:47 UTC (permalink / raw
  Cc: emacs-devel



Kevin Ryde skrev:
> Masatake YAMATO <jet@gyve.org> writes:
>> The problem I found was that etags crashed when `#line 123 L"wide"' was given
>> as input. If the crashing can be suppressed, it is enough.
> 
> That's the only bad case, you don't have some strange libc that
> incorrectly counts %n?
> 
> Jan Djärv <jan.h.d@swipnet.se> writes:
>> 	  if (sscanf (lbp->buffer, "#line %d %n\"", &lno, &start) >= 1
>> 	      && lbp->buffer[start] == '"')
> 
> I think that still uses start uninitialized on say "#line 123 ".

No, in that case start will be 10. If the %d matches, sscanf will return 1 and 
in that case %n must match (whitespace is optional).

	Jan D.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2006-08-10  6:47 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-07  3:38 fix the sscanf usage in etags Masatake YAMATO
2006-08-08  9:35 ` Jan Djärv
2006-08-09  0:06 ` Kevin Ryde
2006-08-09  6:57   ` Jan Djärv
2006-08-09  7:57     ` Masatake YAMATO
2006-08-09 13:20       ` Jan Djärv
2006-08-09 14:10         ` Masatake YAMATO
2006-08-10  0:15     ` Kevin Ryde
2006-08-10  6:47       ` Jan Djärv

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).