Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-10 Thread John Rigg
On Fri, Nov 09, 2012 at 03:24:56PM +0100, Muffinman wrote:
 Yeah, that explains why I didn't get any compiling error on a 32bit
 computer and did get on a 64bit one (where I did correct the error).
 However, the latter was satisfied with %li. Apparently in c++ there is
 no difference between long and long int (as far as I can find through
 Google) but for c I could not find much info on a potential difference.

long is the same as long int in both. The problem is that int and long int
are both 32 bits on i386, but on x86-64 int is 32 and long int is 64 bits.

John
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-10 Thread Robin Gareus
On 11/10/2012 10:35 AM, John Rigg wrote:
 On Fri, Nov 09, 2012 at 03:24:56PM +0100, Muffinman wrote:
 Yeah, that explains why I didn't get any compiling error on a 32bit
 computer and did get on a 64bit one (where I did correct the error).
 However, the latter was satisfied with %li. Apparently in c++ there is
 no difference between long and long int (as far as I can find through
 Google) but for c I could not find much info on a potential difference.
 
 long is the same as long int in both. The problem is that int and long int
 are both 32 bits on i386, but on x86-64 int is 32 and long int is 64 bits.

spot on. It's architecture dependent. Here's an index:

http://www.makelinux.net/ldd3/chp-11-sect-1

For printing, one can use inttypes.h
  printf(val= PRId64 \n, (int64_t) val);

The only problematic one is size_t. printf's %z %Z is a GNU libc extension.

Back on topic, a good general introduction to pointers, malloc etc is
http://cslibrary.stanford.edu/102/PointersAndMemory.pdf

ciao,
robin
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-09 Thread Muffinman
On 09-11-12 01:58, Jacob wrote:

 And, BTW, pay attention to the format ‘%i’ expects type ‘int’ type of
 warnings. Using the wrong or omitting required length modifiers can lead
 to segfaults, too. Even if '%d' and '%ld' refer to integers of the same
 size on an i386 platform, on a 64 bit platform they won't and weird
 things can happen if the argument doesn't match the format spec.
 
 Jacob


Yeah, that explains why I didn't get any compiling error on a 32bit
computer and did get on a 64bit one (where I did correct the error).
However, the latter was satisfied with %li. Apparently in c++ there is
no difference between long and long int (as far as I can find through
Google) but for c I could not find much info on a potential difference.

Perhaps the resource provided by Tristan can help with that (@Tristan:
btw, thanks for that). I will go through that in the coming week.

Maarten
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-09 Thread Paul Davis
On Fri, Nov 9, 2012 at 9:24 AM, Muffinman n...@koster.tk wrote:


 Apparently in c++ there is
 no difference between long and long int (as far as I can find through
 Google) but for c I could not find much info on a potential difference.


they are different in C++ as well.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-09 Thread Karl Hammar
Maarten:
 On 09-11-12 01:58, Jacob wrote:
 
  And, BTW, pay attention to the format %i expects type int type of
  warnings. Using the wrong or omitting required length modifiers can lead
  to segfaults, too. Even if '%d' and '%ld' refer to integers of the same
  size on an i386 platform, on a 64 bit platform they won't and weird
  things can happen if the argument doesn't match the format spec.
  
  Jacob
 
 
 Yeah, that explains why I didn't get any compiling error on a 32bit
 computer and did get on a 64bit one (where I did correct the error).
 However, the latter was satisfied with %li. Apparently in c++ there is
 no difference between long and long int (as far as I can find through
 Google)

 but for c I could not find much info on a potential difference.

 If you look in the c standard or one of its drafts, e.g. this one:

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

In (pdf)page 111 (written page 99) you'll find:

[qoute]

6.7.2 Type specifiers

...

2 At least one type specifier shall be given in the declaration specifiers in 
each declaration,
  and in the specifier-qualifier list in each struct declaration and type name. 
Each list of
  type specifiers shall be one of the following sets (delimited by commas, when 
there is
  more than one set on a line); the type specifiers may occur in any order, 
possibly
  intermixed with the other declaration specifiers.
  -- void
  -- char
  -- signed char
  -- unsigned char
  -- short, signed short, short int, or signed short int
  -- unsigned short, or unsigned short int
  -- int, signed, or signed int

[newpage]

-- unsigned, or unsigned int
-- long, signed long, long int, or signed long int
-- unsigned long, or unsigned long int
-- long long, signed long long, long long int, or
   signed long long int
-- unsigned long long, or unsigned long long int
-- float
-- double
-- long double
-- _Bool
-- float _Complex
-- double _Complex
-- long double _Complex
-- struct or union specifier
-- enum specifier
-- typedef name

...

5 Each of the comma-separated sets designates the same type, except that for 
bit-fields, it is
  implementation-defined whether the specifier int designates the same type as 
signed
  int or the same type as unsigned int.

[end qoute]

I.e. long and long int designates the same type.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-09 Thread Paul Davis
On Fri, Nov 9, 2012 at 9:37 AM, Paul Davis p...@linuxaudiosystems.comwrote:



 On Fri, Nov 9, 2012 at 9:24 AM, Muffinman n...@koster.tk wrote:


 Apparently in c++ there is
 no difference between long and long int (as far as I can find through
 Google) but for c I could not find much info on a potential difference.


 they are different in C++ as well.


i am sorry, i misread this thinking you said long and long long. sincere
apologies for the confusion.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-08 Thread Brett McCoy
On Thu, Nov 8, 2012 at 3:42 PM, Muffinman n...@koster.tk wrote:

 I'm working on a little app utilizing 'lasound' and I've got bassically
 what I want. However, somewhere there is a fault. Editing a random
 variable causes a segmentation fault. I've tried gdb but except it
 telling me where the application crashed (which I already knew) I did
 not get anything useful out of it. To minimize my own potential errors I
 have here below the example script from where I started (though I have
 removed some unnecessary stuff) and commented out the 'long *outvl' and
 '*outvl = -1'. Uncommenting, compile, and run this and I get a
 segmentation fault.

You never allocate memory for the pointer long *outvl after you create
it, but then try to point to a value. You need to use malloc() to
initialize the memory for that pointer before you can use it.

-- 
Brett W. McCoy -- http://www.brettwmccoy.com

In the rhythm of music a secret is hidden; If I were to divulge it,
it would overturn the world.
-- Jelaleddin Rumi
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-08 Thread Muffinman
On 08-11-12 22:02, Brett McCoy wrote:
 
 You never allocate memory for the pointer long *outvl after you create
 it, but then try to point to a value. You need to use malloc() to
 initialize the memory for that pointer before you can use it.
 


Thanks!! I believe I have some more reading to do.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] C - Change in memory causing seg.fault (but why?)

2012-11-08 Thread Jacob

On 11/08/2012 10:18 PM, Muffinman wrote:

On 08-11-12 22:02, Brett McCoy wrote:


You never allocate memory for the pointer long *outvl after you create
it, but then try to point to a value. You need to use malloc() to
initialize the memory for that pointer before you can use it.




Thanks!! I believe I have some more reading to do.


And, BTW, pay attention to the format ‘%i’ expects type ‘int’ type of
warnings. Using the wrong or omitting required length modifiers can lead
to segfaults, too. Even if '%d' and '%ld' refer to integers of the same
size on an i386 platform, on a 64 bit platform they won't and weird 
things can happen if the argument doesn't match the format spec.


Jacob

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev