Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > [MUDFLAP] Is sizeof(ARRAY[0]) equivalent to sizeof(*ARRAY) ?

Reply
Thread Tools

[MUDFLAP] Is sizeof(ARRAY[0]) equivalent to sizeof(*ARRAY) ?

 
 
m.labanowicz@gmail.com
Guest
Posts: n/a
 
      01-10-2013
W dniu czwartek, 10 stycznia 2013 15:37:45 UTC+1 użytkownik Ben Bacarisse napisał:
> http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
>
>
>
> > Ok, after long investigation I have successfully prepared simple C

>
> > program that illustrates the issue:

>
> > 3 files:

>
> > - bar.h

>
> > - bar.c

>
> > - main.c

>
>
>
> A data point: your example compiles and runs clean with gcc 4.7.2 and
>
> mudflap 4.7.
>
>


Thanks for information.
I'm going to update my system with newer GCC+MUDFLAP.

--
Maciek


 
Reply With Quote
 
 
 
 
Shao Miller
Guest
Posts: n/a
 
      01-10-2013
On 1/10/2013 09:48, (E-Mail Removed) wrote:
> 02: mudflap violation 1 (register): time=1357829219.568594 ptr=0xbfd9f6b8 size=72
> 03: pc=0xb762b85e
> 04: /usr/lib/i386-linux-gnu/libmudflap.so.0(__mf_register+0x3e) [0xb762b85e]
> 05: ./a.out() [0x8048979]
> 06: ./a.out() [0x80489e2]
> 07: Nearby object 1: checked region begins 8B into and ends 79B into
> 08: mudflap object 0x9a021e8: name=`constant'
> 09: bounds=[0xbfd9f6b0,0xbfd9f6ff] size=80 area=static check=0r/0w liveness=0
> 10: alloc time=1357829219.568588 pc=0xb762b85e
> 11: number of nearby objects: 1
> 12: mf: alloca stack level 0xbfd9f5a8


Oops. Missed 'alloca', before. I'd guess that it has a bug. If you
change your arrays to 'static' storage duration, perhaps the problem
would disappear, as 'alloca' wouldn't be used. - Shao

 
Reply With Quote
 
 
 
 
m.labanowicz@gmail.com
Guest
Posts: n/a
 
      01-10-2013
> > A data point: your example compiles and runs clean with gcc 4.7.2 and
>
> >

>
> > mudflap 4.7.


Upgraded GCC to 4.7:
Linux ldrlinux 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux
gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
libmudflap0-4.7-dev

Issue is still present - today I'm giving up

--
Maciek
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-10-2013
(E-Mail Removed) writes:

>> > A data point: your example compiles and runs clean with gcc 4.7.2 and

>>
>> >

>>
>> > mudflap 4.7.

>
> Upgraded GCC to 4.7:
> Linux ldrlinux 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux
> gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
> libmudflap0-4.7-dev
>
> Issue is still present - today I'm giving up


Just to confirm:

$ gcc -ansi -pedantic -Wall -W -Werror -fmudflap bar.c main.c -lmudflap
$ ./a.out
Hello World !
foo_fun = 234930176
bar_fun = 1564
$ gcc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright © 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ dpkg -s libmudflap0
Package: libmudflap0
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 270
Maintainer: Ubuntu Core developers <(E-Mail Removed)>
Architecture: amd64
Multi-Arch: same
Source: gcc-4.7
Version: 4.7.2-2ubuntu1
Depends: gcc-4.7-base (= 4.7.2-2ubuntu1), libc6 (>= 2.14)
Pre-Depends: multiarch-support
Breaks: gcc-4.1, gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2)
Description: GCC mudflap shared support libraries
The libmudflap libraries are used by GCC for instrumenting pointer and array
dereferencing operations.
Homepage: http://gcc.gnu.org/
Original-Maintainer: Debian GCC Maintainers <(E-Mail Removed)>
$ uname -a
Linux tinky 3.5.0-21-generic-tuxonice #32~ppa1-Ubuntu SMP Tue Dec 18 20:29:04 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

--
Ben.
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      01-10-2013
On 1/10/2013 10:41, (E-Mail Removed) wrote:
>>> A data point: your example compiles and runs clean with gcc 4.7.2 and

>>
>>>

>>
>>> mudflap 4.7.

>
> Upgraded GCC to 4.7:
> Linux ldrlinux 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux
> gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
> libmudflap0-4.7-dev
>
> Issue is still present - today I'm giving up
>


I was unable to reproduce the violations with:
- gcc version 4.7.2 20120921 (Red Hat 4.7.2-2)
- libmudflap 4.7.2, release 2.fc17

- Shao Miller
 
Reply With Quote
 
m.labanowicz@gmail.com
Guest
Posts: n/a
 
      01-11-2013
I have executed this test on UBUNTU 12.04 on 64 bit machine and issue is not present.

BUT, after change the type of the elemnt array from int(4bytes) to long(8bytes) issue comes back:

--------------------------
+ uname -a
Linux qa-stream-server 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
+ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ dpkg -s libmudflap0
Package: libmudflap0
Status: install ok installed
Multi-Arch: same
Priority: optional
Section: libs
Installed-Size: 266
Maintainer: Ubuntu Core developers <(E-Mail Removed)>
Architecture: amd64
Source: gcc-4.6
Version: 4.6.3-1ubuntu5
Depends: gcc-4.6-base (= 4.6.3-1ubuntu5), libc6 (>= 2.14)
Pre-Depends: multiarch-support
Breaks: gcc-4.1, gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2)
Description: GCC mudflap shared support libraries
The libmudflap libraries are used by GCC for instrumenting pointer and array
dereferencing operations.
Homepage: http://gcc.gnu.org/
Original-Maintainer: Debian GCC Maintainers <(E-Mail Removed)>
+ gawk '{printf("%02u: %s\n", NR, $0);}' bar.h
01: int bar_fun(unsigned idx);
02: #define ARRAY_NO_OF_ELEMENTS(a) ((unsigned)(sizeof(a) / sizeof(*a)))
+ gawk '{printf("%02u: %s\n", NR, $0);}' bar.c
01: #include "bar.h"
02: int bar_fun(unsigned idx)
03: {
04: long bar_cfg [][2] =
05: {
06: {9, 0},
07: {8, 1},
08: {7, 2},
09: {6, 3},
10: {5, 4},
11: {4, 5},
12: {3, 6},
13: {2, 7},
14: #ifdef WORKAROUND_FOR_MUDFLAP
15: {1, 8},
16: #endif
17: {0, 9}
18: };
19: return (idx < ARRAY_NO_OF_ELEMENTS(bar_cfg)) ? (int)(bar_cfg[idx][1]) : -1;
20: }
+ gawk '{printf("%02u: %s\n", NR, $0);}' main.c
01: #include <stdio.h> /* printf */
02: #include <stdlib.h> /* EXIT_SUCCESS */
03: #include "bar.h"
04: static int foo_fun(unsigned idx)
05: {
06: long const TOSTEP [][2] =
07: {
08: {0, 9},
09: {1, 8},
10: {2, 7},
11: {3, 6},
12: {4, 5},
13: {5, 4},
14: {6, 3},
15: {7, 2},
16: {8, 1},
17: {9, 0}
18: };
19: return (idx < ARRAY_NO_OF_ELEMENTS(TOSTEP)) ? (int)(TOSTEP[idx][1]) : -1;
20: }
21: int main(void)
22: {
23: printf("Hello World ! (c=%u,s=%u,i=%u,l=%u,p=%u)\r\n", \
24: (unsigned)sizeof(char), (unsigned)sizeof(short), \
25: (unsigned)sizeof(int), (unsigned)sizeof(long), \
26: (unsigned)sizeof(void *));
27: printf("foo_fun = %d\r\n", foo_fun(4));
28: printf("bar_fun = %d\r\n", bar_fun(4));
29: return EXIT_SUCCESS;
30: }
+ export 'MUDFLAP_OPTIONS=-mode-check -viol-nop -verbose-trace -internal-checking -print-leaks -check-initialization -verbose-violations'
+ MUDFLAP_OPTIONS='-mode-check -viol-nop -verbose-trace -internal-checking -print-leaks -check-initialization -verbose-violations'
+ gcc -ggdb -g3 -ansi -pedantic -Wall -W -Werror -fmudflap bar.c main.c -lmudflap
+ ./a.out
+ gawk '{printf("%02u: %s\n", NR, $0);}'
01: *******
02: mudflap violation 1 (register): time=1357902146.588238 ptr=0x7fff9312cfd0 size=160
03: pc=0x7ff09ad05291
04: /usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_register+0x41) [0x7ff09ad05291]
05: ./a.out() [0x400d0f]
06: ./a.out(__libc_csu_init+0x5d) [0x400dbd]
07: Nearby object 1: checked region begins 16B before and ends 143B into
08: mudflap object 0x22d6370: name=`constant'
09: bounds=[0x7fff9312cfe0,0x7fff9312d06f] size=144 area=static check=0r/0w liveness=0
10: alloc time=1357902146.588237 pc=0x7ff09ad05291
11: number of nearby objects: 1
12: mf: alloca stack level 0x7fff9312cf20
13: Hello World ! (c=1,s=2,i=4,l=8,p=
14: foo_fun = 5
15: bar_fun = 4
16: *******
17: mudflap violation 2 (unregister): time=1357902146.588445 ptr=0x22d6970 size=0
18: pc=0x7ff09ad04e36
19: number of nearby objects: 0
20: number of leaked objects: 0
+ gcc -ggdb -g3 -ansi -pedantic -Wall -W -Werror -fmudflap -DWORKAROUND_FOR_MUDFLAP bar.c main.c -lmudflap
+ ./a.out
+ gawk '{printf("%02u: %s\n", NR, $0);}'
01: mf: harmless duplicate reg 0x7fff7ffebcc0-0x7fff7ffebd5f `constant'
02: mf: alloca stack level 0x7fff7ffebc20
03: Hello World ! (c=1,s=2,i=4,l=8,p=
04: foo_fun = 5
05: bar_fun = 4
06: number of leaked objects: 0
--------------------------

I'm going to check that issue on GCC 4.7.

--
Maciek
 
Reply With Quote
 
m.labanowicz@gmail.com
Guest
Posts: n/a
 
      01-11-2013
W dniu piątek, 11 stycznia 2013 12:03:51 UTC+1 użytkownik (E-Mail Removed) napisał:
> I have executed this test on UBUNTU 12.04 on 64 bit machine and issue is not present.
> BUT, after change the type of the elemnt array from int(4bytes) to long(8bytes) issue comes back:
>

....
>
> I'm going to check that issue on GCC 4.7.
>


GCC 4.7 (64bitMachine) issue still present:
$ uname -a
Linux qa-stream-server 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ dpkg -s libmudflap0
Package: libmudflap0
Status: install ok installed
Multi-Arch: same
Priority: optional
Section: libs
Installed-Size: 270
Maintainer: Ubuntu Core developers <(E-Mail Removed)>
Architecture: amd64
Source: gcc-4.7
Version: 4.7.2-11precise2
Depends: gcc-4.7-base (= 4.7.2-11precise2), libc6 (>= 2.14)
Pre-Depends: multiarch-support
Breaks: gcc-4.1, gcc-4.3 (<< 4.3.6-1), gcc-4.4 (<< 4.4.6-4), gcc-4.5 (<< 4.5.3-2)
Description: GCC mudflap shared support libraries
The libmudflap libraries are used by GCC for instrumenting pointer and array
dereferencing operations.
Homepage: http://gcc.gnu.org/
Original-Maintainer: Debian GCC Maintainers <(E-Mail Removed)>

--
Maciek
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-11-2013
On 01/11/2013 07:14 AM, (E-Mail Removed) wrote:
[more on problems with gcc -mudflap]

I'm curious - why haven't you followed up yet on my suggestion that you
take this question to a gcc forum, such as gnu.gcc.help, where you're
likely to get better answers to your question?

Also, see <http://gcc.gnu.org/bugs/>. <http://gcc.gnu.org/bugzilla/>
lists 64 open bugs containing the word "mudflap". I'd recommend checking
whether any of those bugs matches your problem, before filing a new one.

--
James Kuyper
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-11-2013
Shao Miller <(E-Mail Removed)> writes:
[...]
> MUDFLAP can diagnose stuff that's permitted by C90, such as warning you
> that an index used for iteration has gone too far. Usually you want to
> index one-past an array, at most. Do the 'for' loops have any problems?


As I'm sure you know, it's legal to construct a pointer one element
past the end of an array, but not to dererence it. Constructing a
pointer before the beginning of an array or more than one element
past the end of it, or deferencing a pointer one past the end of it,
has undefined behavior. I'm not aware of any relevant changes in
this area from C90 to C99 to C11.

Are you saying that Mudflap complains about stuff that's legal *and
has defined behavior* in C90? If it complained about something
like this:

int arr[N];
int *ptr;
for (ptr = arr; ptr < arr + N; ptr ++) {
/* ... */
}

that would IMHO be a serious bug in Mudflap.

(I haven't analyzed the posted code, but from the discussion I don't
think that's what's going on.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      01-11-2013
On 1/11/2013 11:19, Keith Thompson wrote:
> Shao Miller <(E-Mail Removed)> writes:
> [...]
>> MUDFLAP can diagnose stuff that's permitted by C90, such as warning you
>> that an index used for iteration has gone too far. Usually you want to
>> index one-past an array, at most. Do the 'for' loops have any problems?

>
> As I'm sure you know, it's legal to construct a pointer one element
> past the end of an array, but not to dererence it. Constructing a
> pointer before the beginning of an array or more than one element
> past the end of it, or deferencing a pointer one past the end of it,
> has undefined behavior. I'm not aware of any relevant changes in
> this area from C90 to C99 to C11.
>
> Are you saying that Mudflap complains about stuff that's legal *and
> has defined behavior* in C90? If it complained about something
> like this:
>
> int arr[N];
> int *ptr;
> for (ptr = arr; ptr < arr + N; ptr ++) {
> /* ... */
> }
>
> that would IMHO be a serious bug in Mudflap.
>
> (I haven't analyzed the posted code, but from the discussion I don't
> think that's what's going on.)
>


Nah, I tried to be careful and chose to type "index" instead of "point".
The code I was criticizing used both an integer index as well as a
pointer. Their pointer would never point more than one past the array,
but their integer would index two past the array. That seems to be
permitted by C90.

I seem to recall some bit about this situation being easily detectable
and reportable as a bonus diagnostic, perhaps in the hopes of alerting
the programmer that there's a better way to write their loop without
stepping out of bounds, conceptually.

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Warning:Xst:382 - Register A is equivalent to B mag VHDL 1 05-19-2005 05:10 PM
instancename of current entity/architecture -- equivalent to C++ this??? Eric Peers VHDL 2 11-18-2004 05:23 PM
VHDL equivalent of verilog trireg Sanjeev VHDL 4 07-23-2004 09:55 AM
equivalent types in different packages Lolo VHDL 3 09-22-2003 03:23 PM
Re: Image Scanning - TWAIN equivalent Brendan Duffy ASP .Net 0 07-24-2003 08:29 AM



Advertisments