Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #107864 > unrolled thread

Need help fixing a "previously defined" error

Back to article view | Back to comp.lang.c

Contents

  Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 08:07 -0500
    Re: Need help fixing a "previously defined" error James Kuyper <jameskuyper@verizon.net> - 2017-04-08 10:47 -0400
      Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 12:51 -0500
        Re: Need help fixing a "previously defined" error Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-08 20:03 +0100
        Re: Need help fixing a "previously defined" error Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 19:06 +0000
        Re: Need help fixing a "previously defined" error James Kuyper <jameskuyper@verizon.net> - 2017-04-08 15:17 -0400
    Re: Need help fixing a "previously defined" error Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 15:29 +0000
    Re: Need help fixing a "previously defined" error Barry Schwarz <schwarzb@dqel.com> - 2017-04-08 09:21 -0700
      Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 13:04 -0500
        Re: Need help fixing a "previously defined" error James Kuyper <jameskuyper@verizon.net> - 2017-04-08 15:33 -0400
          Re: Need help fixing a "previously defined" error Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 19:51 +0000
          Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 16:24 -0500
      Re: Need help fixing a "previously defined" error Keith Thompson <kst-u@mib.org> - 2017-04-08 18:45 -0700
    Re: Need help fixing a "previously defined" error bartc <bc@freeuk.com> - 2017-04-08 17:46 +0100
      Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 13:19 -0500
    Re: Need help fixing a "previously defined" error David Brown <david.brown@hesbynett.no> - 2017-04-09 12:38 +0200
      Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-09 07:52 -0500
        Re: Need help fixing a "previously defined" error David Brown <david.brown@hesbynett.no> - 2017-04-09 17:02 +0200
          Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-09 18:20 -0500
            Re: Need help fixing a "previously defined" error James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:06 -0400
            Re: Need help fixing a "previously defined" error David Brown <david.brown@hesbynett.no> - 2017-04-10 09:07 +0200
              Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-10 09:11 -0500
                Re: Need help fixing a "previously defined" error David Brown <david.brown@hesbynett.no> - 2017-04-10 17:31 +0200
                  Re: Need help fixing a "previously defined" error Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-10 12:48 -0500

Page 1 of 2  [1] 2  Next page →

#107864 — Need help fixing a "previously defined" error

As will shortly be obvious, I'm completely new to C.  I'm trying to 
modify and recompile a Texas Instruments program called BSLDEMO2.exe 
which is used to flash new firmware to some of their MSP430 
microprocessors using a boot-strap loader. I need to invert the DTR line. 
They provide the source code, which they compiled using a Microsoft 
compiler.  I'm using LCC.  And this is C, not C++.

Before addressing the change I want to make, I'm just trying to get the 
original source to compile in LCC.  I'm getting a "previously defined" 
error that I don't quite know how to deal with.

The file is TI_TXT_Files.h, and it starts off this way:

---------------------------------------------------------

#ifndef _TI_TXT_Files_H_
#define _TI_TXT_Files_H_

/***********************/
/* Function prototypes */
/***********************/

char* strtrim(char* lpszA);
BOOL GetAddress(char* Record, unsigned long* ulAddress);
BOOL GetBytes(char* Record, BYTE Bytes[], unsigned int* ByteCnt);

long Load_Ti_Txt(LPTSTR File);

//-- StartTITextOutput 

--------------------------------------------------------

LCC says "strtrim" is previously defined in the #included <string.h>.

I guess the first question is what that char* line is doing. The second 
question is why didn't TI get this error when they compiled it.  But 
the main question is how to fix it.

LCC's string.h has this:

#ifndef __ANSIC__ONLY__
short *  memshort(const short *,short,size_t);
unsigned short *memushort(const unsigned short *,unsigned short,size_t);
int *    memint(const int *,int,size_t);
unsigned int *memuint(const unsigned int *,unsigned int,size_t);
long long *memll(const long long *,long long,size_t);
unsigned long long *memull(const unsigned long long *,unsigned long 
long,size_t);
char    *strupr(char *);
char    *strlwr(char *);
char    *strnupr(char *,size_t);
char    *strnlwr(char *,size_t);
int      strtrim(char *);           <============= here
char    *strrev(char *);
#endif

On the surface there seems to be a conflict between the char* and the int 
declarations.  But that's probably because I don't understand what's 
going on.

There are no other instances of "strtrim" appearing anywhere in the TI 
source code.

It seems that the safest way to deal with this might be to make a copy of 
string.h with the strtrim declaration commented out, and move it up to 
the source code folder, and change all <string.h> #includes to 
"string.h".  Would that work?  Is there a better way?

I would appreciate any suggestions.

[toc] | [next] | [standalone]

#107869

On 04/08/2017 09:07 AM, Peabody wrote:
> As will shortly be obvious, I'm completely new to C.  I'm trying to 
> modify and recompile a Texas Instruments program called BSLDEMO2.exe 
> which is used to flash new firmware to some of their MSP430 
> microprocessors using a boot-strap loader. I need to invert the DTR line. 
> They provide the source code, which they compiled using a Microsoft 
> compiler.  I'm using LCC.  And this is C, not C++.
> 
> Before addressing the change I want to make, I'm just trying to get the 
> original source to compile in LCC.  I'm getting a "previously defined" 
> error that I don't quite know how to deal with.
> 
> The file is TI_TXT_Files.h, and it starts off this way:
...
> char* strtrim(char* lpszA);
...
> LCC says "strtrim" is previously defined in the #included <string.h>.
> 
> I guess the first question is what that char* line is doing. ...

It declares that strtrim identifies a function that takes one argument
of type char*, and returns a value of type char*. The "lpszA" is purely
decorative as far as C itself is concerned. It uses prefixes that tell
you something about the meaning of the string that it points at, but I'm
not familiar with those prefixes.

> ... The second 
> question is why didn't TI get this error when they compiled it. ...

Most likely because they used the Microsoft compiler, while you used
LCC. The C standard gives implementations a lot of freedom to differ
from each other, and "strtrim" is one example of that. strtrim() is NOT
part of the C standard library, so this might seem to be a
non-conforming implementation of <string.h>. However, 7.31.13 says that
names beginning with "str", "mem", or "wcs" followed by a lower case
letter may be added to future versions of <string.h>, and according to
7.1.3p1, all such names are therefore reserved for use as identifiers
with external linkage. strtrim matches that pattern. Because such names
are reserved, LCC is entitled to add such names to it's own version of
<stdio.h>, and the TI code has undefined behavior.
"Undefined behavior" means that Microsoft compiler is free to accept
such code and have it execute exactly as expected, but it also means
that LCC is allowed to reject such code.

> ...  But 
> the main question is how to fix it.
> 
> LCC's string.h has this:
> 
> #ifndef __ANSIC__ONLY__
...
> int      strtrim(char *);           <============= here
...
> #endif
> 
> On the surface there seems to be a conflict between the char* and the int 
> declarations. ...

That is precisely the conflict that is causing the problem. There are
implementations where char* and int can be successfully type-punned for
each other, but it's not anything you can count on portably. They're not
even remotely compatible types as far as the C standard is concerned.

> There are no other instances of "strtrim" appearing anywhere in the TI 
> source code.

The TI code declares strtrim(), but makes no use of it? That's weird,
but unused declarations are not uncommon in code that has a lot of
history. If so, that's trivial to deal with - just remove the declaration.
If you made a mistake while searching for other uses of strtrim,
removing that declaration will help you find them. If you do end up
finding some, the problem gets much more complicated. In that case, let
us know precisely how it is used, and we might be able to suggest a
work-around.

> It seems that the safest way to deal with this might be to make a copy of 
> string.h with the strtrim declaration commented out, and move it up to 
> the source code folder, and change all <string.h> #includes to 
> "string.h".  Would that work?  Is there a better way?

Modifying standard headers is job to be done only by experts, and most
experts know enough to not do it. You're much better off changing the TI
code.

[toc] | [prev] | [next] | [standalone]

#107877

James Kuyper says...

 > It declares that strtrim identifies a function that
 > takes one argument of type char*, and returns a value of
 > type char*. The "lpszA" is purely decorative as far as C
 > itself is concerned. It uses prefixes that tell you
 > something about the meaning of the string that it points
 > at, but I'm not familiar with those prefixes.

 > Most likely because they used the Microsoft compiler,
 > while you used LCC. The C standard gives implementations
 > a lot of freedom to differ from each other, and
 > "strtrim" is one example of that. strtrim() is NOT part
 > of the C standard library, so this might seem to be a
 > non-conforming implementation of <string.h>. However,
 > 7.31.13 says that names beginning with "str", "mem", or
 > "wcs" followed by a lower case letter may be added to
 > future versions of <string.h>, and according to 7.1.3p1,
 > all such names are therefore reserved for use as
 > identifiers with external linkage. strtrim matches that
 > pattern. Because such names are reserved, LCC is
 > entitled to add such names to it's own version of
 > <stdio.h>, and the TI code has undefined behavior.
 > "Undefined behavior" means that Microsoft compiler is
 > free to accept such code and have it execute exactly as
 > expected, but it also means that LCC is allowed to
 > reject such code.

Ok, but what's confusing me is that "StrTrim" is a legit
Microsoft string function, although possibly (only) for C++:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
(v=vs.85).aspx

So is this just a mistake - the wrong case chosen for the
letters - and TI is really trying to call the MS
function to trim a string?  But what string would that be?
"lpszA" doesn't appear anywhere else in the source code
either, but I think it also has some kind of special meaning
involving Unicode.

 > The TI code declares strtrim(), but makes no use of it?
 > That's weird, but unused declarations are not uncommon
 > in code that has a lot of history. If so, that's trivial
 > to deal with - just remove the declaration. If you made
 > a mistake while searching for other uses of strtrim,
 > removing that declaration will help you find them.

I did try that, and the compile worked.  But somehow I'm not
comfortable with it not needing to be there.  This part of
the code has to do with writing strings to a .txt file where
you would not want trailing spaces or null terminations.

[toc] | [prev] | [next] | [standalone]

#107887

Peabody <waybackNO584SPAM44@yahoo.com> writes:
<snip>

> Ok, but what's confusing me is that "StrTrim" is a legit
> Microsoft string function, although possibly (only) for C++:
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
> (v=vs.85).aspx

C (and C++) are case-sensitive so that's not the same function at all.

> So is this just a mistake - the wrong case chosen for the
> letters - and TI is really trying to call the MS
> function to trim a string?

The code you posted is not calling the function (i.e. using it) it is
merely declaring it -- in this case, telling the compiler what the
arguments types to expect and what type the return value has.

Almost certainly there will be at least other uses of that name.  One
will a definition of the function and another will be a call to it.  Of
course, there may be many calls but there should be only one definition.

> But what string would that be?
> "lpszA" doesn't appear anywhere else in the source code
> either, but I think it also has some kind of special meaning
> involving Unicode.

It's fake name.  A declaration does not need to name the arguments but
people often put one in to "help out" or sometimes the first line of the
function definition (which does need names) is copied to make the
declaration.  One way or another all of these are the same:

  char* strtrim(char* lpszA);
  char* strtrim(char*);
  char* strtrim(char* string);
  char* strtrim(char* long_pointer_to_start_of_zero_terminated_ASCII_string);

That last one is a guess at what "lpszA" is suppose to convey to those
who have been initiated (or indoctrinated) into the cabal.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#107889

On Sat, 08 Apr 2017 12:51:08 -0500
Peabody <waybackNO584SPAM44@yahoo.com> wrote:
> James Kuyper says...
> 
>  > It declares that strtrim identifies a function that
>  > takes one argument of type char*, and returns a value of
>  > type char*. The "lpszA" is purely decorative as far as C
>  > itself is concerned. It uses prefixes that tell you
>  > something about the meaning of the string that it points
>  > at, but I'm not familiar with those prefixes.
> 
>  > Most likely because they used the Microsoft compiler,
>  > while you used LCC. The C standard gives implementations
>  > a lot of freedom to differ from each other, and
>  > "strtrim" is one example of that. strtrim() is NOT part
>  > of the C standard library, so this might seem to be a
>  > non-conforming implementation of <string.h>. However,
>  > 7.31.13 says that names beginning with "str", "mem", or
>  > "wcs" followed by a lower case letter may be added to
>  > future versions of <string.h>, and according to 7.1.3p1,
>  > all such names are therefore reserved for use as
>  > identifiers with external linkage. strtrim matches that
>  > pattern. Because such names are reserved, LCC is
>  > entitled to add such names to it's own version of
>  > <stdio.h>, and the TI code has undefined behavior.
>  > "Undefined behavior" means that Microsoft compiler is
>  > free to accept such code and have it execute exactly as
>  > expected, but it also means that LCC is allowed to
>  > reject such code.
> 
> Ok, but what's confusing me is that "StrTrim" is a legit
> Microsoft string function, although possibly (only) for C++:
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
> (v=vs.85).aspx
> 
> So is this just a mistake - the wrong case chosen for the
> letters - and TI is really trying to call the MS
> function to trim a string?

From your link in does look like C++ .In any case , C is case sensitive
and StrTrim is a different identifier than strtrim .So the presence of
the  strtrim  declaration does not affect anything the code might want
to do with a  StrTrim  function.

> But what string would that be?

Not enough evidence to even speculate.

> "lpszA" doesn't appear anywhere else in the source code
> either, but I think it also has some kind of special meaning
> involving Unicode.

You wouldn't necessarily expect  lpszA  to appear in the definition
of the function. A declaration
    char* strtrim(char* lpszA);
could equally well be written as
    char* strtrim(char*);

The definition of the function may be using something other than
lpszA  as the name of the passed argument.

>  > The TI code declares strtrim(), but makes no use of it?
>  > That's weird, but unused declarations are not uncommon
>  > in code that has a lot of history. If so, that's trivial
>  > to deal with - just remove the declaration. If you made
>  > a mistake while searching for other uses of strtrim,
>  > removing that declaration will help you find them.
> 
> I did try that, and the compile worked.  But somehow I'm not
> comfortable with it not needing to be there.  This part of
> the code has to do with writing strings to a .txt file where
> you would not want trailing spaces or null terminations.

The code would have to be doing something very weird to accidentally
write NUL bytes when it only tries to write text. As for trailing
spaces , couldn't you just test that part of the code ?

[toc] | [prev] | [next] | [standalone]

#107890

On 04/08/2017 01:51 PM, Peabody wrote:
> James Kuyper says...
> 
>  > It declares that strtrim identifies a function that
>  > takes one argument of type char*, and returns a value of
>  > type char*. The "lpszA" is purely decorative as far as C
>  > itself is concerned. It uses prefixes that tell you
>  > something about the meaning of the string that it points
>  > at, but I'm not familiar with those prefixes.
> 
>  > Most likely because they used the Microsoft compiler,
>  > while you used LCC. The C standard gives implementations
>  > a lot of freedom to differ from each other, and
>  > "strtrim" is one example of that. strtrim() is NOT part
>  > of the C standard library, so this might seem to be a
>  > non-conforming implementation of <string.h>. However,
>  > 7.31.13 says that names beginning with "str", "mem", or
>  > "wcs" followed by a lower case letter may be added to
>  > future versions of <string.h>, and according to 7.1.3p1,
>  > all such names are therefore reserved for use as
>  > identifiers with external linkage. strtrim matches that
>  > pattern. Because such names are reserved, LCC is
>  > entitled to add such names to it's own version of
>  > <stdio.h>, and the TI code has undefined behavior.
>  > "Undefined behavior" means that Microsoft compiler is
>  > free to accept such code and have it execute exactly as
>  > expected, but it also means that LCC is allowed to
>  > reject such code.
> 
> Ok, but what's confusing me is that "StrTrim" is a legit
> Microsoft string function, although possibly (only) for C++:

C is case sensitive, so StrTrim is a completely different identfier from
strtrim.

> https://msdn.microsoft.com/en-us/library/windows/desktop/bb773454
> (v=vs.85).aspx
> 
> So is this just a mistake - the wrong case chosen for the
> letters - and TI is really trying to call the MS
> function to trim a string?

That's quite unlikely. It was probably intended to call some other
function named strtrim (and NOT StrTrim) to trim a string. That
particular name is fairly popular.

> ...  But what string would that be?

If you found no other occurrences of strtrim() in the code, then it
isn't currently being called for any string. In code that has been
around for a long time, this is not uncommon - there used to be a call
to strtrim(), but it got removed, but the person who removed it forgot
to remove the declaration for strtrm().

> "lpszA" doesn't appear anywhere else in the source code

As I said, that's purely decorative - it has no meaning that matters as
far as C code is concerned. In particular, it doesn't have to match
anything else (in fact, if if did match a macro name, the results could
be disastrous).

> either, but I think it also has some kind of special meaning
> involving Unicode.

No.

>  > The TI code declares strtrim(), but makes no use of it?
>  > That's weird, but unused declarations are not uncommon
>  > in code that has a lot of history. If so, that's trivial
>  > to deal with - just remove the declaration. If you made
>  > a mistake while searching for other uses of strtrim,
>  > removing that declaration will help you find them.
> 
> I did try that, and the compile worked.  But somehow I'm not
> comfortable with it not needing to be there.

Get comfortable with it when looking at other people's code - there's a
lot of sloppy coding practices out there. Removing all uses of a
declaration, without remembering to remove the declaration itself, is an
unfortunately common occurrence. In your own code you should try to
avoid doing that, but it's pretty much unavoidable in other people's code.

[toc] | [prev] | [next] | [standalone]

#107872

On Sat, 08 Apr 2017 08:07:20 -0500
Peabody <waybackNO584SPAM44@yahoo.com> wrote:
> As will shortly be obvious, I'm completely new to C.  I'm trying to 
> modify and recompile a Texas Instruments program called BSLDEMO2.exe 
> which is used to flash new firmware to some of their MSP430 
> microprocessors using a boot-strap loader. I need to invert the DTR line. 
> They provide the source code, which they compiled using a Microsoft 
> compiler.  I'm using LCC.  And this is C, not C++.
> 
> Before addressing the change I want to make, I'm just trying to get the 
> original source to compile in LCC.  I'm getting a "previously defined" 
> error that I don't quite know how to deal with.
> 
> The file is TI_TXT_Files.h, and it starts off this way:
> 
> ---------------------------------------------------------
> 
> #ifndef _TI_TXT_Files_H_
> #define _TI_TXT_Files_H_
> 
> /***********************/
> /* Function prototypes */
> /***********************/
> 
> char* strtrim(char* lpszA);
> BOOL GetAddress(char* Record, unsigned long* ulAddress);
> BOOL GetBytes(char* Record, BYTE Bytes[], unsigned int* ByteCnt);
> 
> long Load_Ti_Txt(LPTSTR File);
> 
> //-- StartTITextOutput 
> 
> --------------------------------------------------------
> 
> LCC says "strtrim" is previously defined in the #included <string.h>.

So somewhere in your source there is a line
#include <string.h>

Try putting at some point in the code *before* that line (possibly that point
in the code should be before any other lines of the
form
#include <some-standard-C-header.h>

) the following

#ifndef __ANSIC__ONLY__
#define __ANSIC__ONLY__
#endif

> I guess the first question is what that char* line is doing. The second 
> question is why didn't TI get this error when they compiled it.  But 
> the main question is how to fix it.
> 
> LCC's string.h has this:
> 
> #ifndef __ANSIC__ONLY__
> short *  memshort(const short *,short,size_t);
> unsigned short *memushort(const unsigned short *,unsigned short,size_t);
> int *    memint(const int *,int,size_t);
> unsigned int *memuint(const unsigned int *,unsigned int,size_t);
> long long *memll(const long long *,long long,size_t);
> unsigned long long *memull(const unsigned long long *,unsigned long 
> long,size_t);
> char    *strupr(char *);
> char    *strlwr(char *);
> char    *strnupr(char *,size_t);
> char    *strnlwr(char *,size_t);
> int      strtrim(char *);           <============= here
> char    *strrev(char *);
> #endif
> 
> On the surface there seems to be a conflict between the char* and the int 
> declarations.  But that's probably because I don't understand what's 
> going on.

No , you understand fine ; that's indeed why you're getting an error message.

> There are no other instances of "strtrim" appearing anywhere in the TI 
> source code.
> 
> It seems that the safest way to deal with this might be to make a copy of 
> string.h with the strtrim declaration commented out, and move it up to 
> the source code folder, and change all <string.h> #includes to 
> "string.h".  Would that work?  Is there a better way?
> 
> I would appreciate any suggestions.

[toc] | [prev] | [next] | [standalone]

#107874

On Sat, 08 Apr 2017 08:07:20 -0500, Peabody
<waybackNO584SPAM44@yahoo.com> wrote:

>As will shortly be obvious, I'm completely new to C.  I'm trying to 
>modify and recompile a Texas Instruments program called BSLDEMO2.exe 
>which is used to flash new firmware to some of their MSP430 
>microprocessors using a boot-strap loader. I need to invert the DTR line. 
>They provide the source code, which they compiled using a Microsoft 
>compiler.  I'm using LCC.  And this is C, not C++.
>
>Before addressing the change I want to make, I'm just trying to get the 
>original source to compile in LCC.  I'm getting a "previously defined" 
>error that I don't quite know how to deal with.
>

<snip>

>LCC's string.h has this:
>
>#ifndef __ANSIC__ONLY__

<snip>

>#endif

The above conditional compilation is LCC's way of acknowledging that
everything in that block is an extension to the language as defined by
the standard.  If you need any of those extensions, then you do not
define the macro __ANSI__ONLY__.  If you don't want the LCC
extensions, then you do define that macro.

Since your project was not originally created with LCC, it seems very
likely that you do not need any of LCC's extensions.  In that case, it
would make sense to define the macro.

This completely ignores the question of whether the original code
required any Microsoft-unique compiler features.  This includes
extensions and compiler eccentricities.  For example, the code may
depend on long and int being the same size or size_t being an unsigned
int.  

Even if the code uses only standard features, there are additional
potential issues due to the evolution of the standard over the years.
For example, it used to be permitted to omit the return type in a
function declaration and the compiler was required to assume the type
was int.  This is now a constraint violation.

The bottom line is merely getting a clean compile should be only the
first step before attempting any modifications.  You also need to
verify that the newly compiled program behaves reasonably similar to
the original program.

>On the surface there seems to be a conflict between the char* and the int 
>declarations.  But that's probably because I don't understand what's 
>going on.
>
>There are no other instances of "strtrim" appearing anywhere in the TI 
>source code.

In that case, you should be able to turn the declaration in the TI
header to a comment.  This will allow LCC to double check your manual
search.  If you missed an occurrence, LCC will issue a diagnostic
because the call statement in the TI source will not match the
prototype in the LCC header.  (Or if you define the macro, it will
report the absence of a prototype.)

>It seems that the safest way to deal with this might be to make a copy of 
>string.h with the strtrim declaration commented out, and move it up to 
>the source code folder, and change all <string.h> #includes to 
>"string.h".  Would that work?  Is there a better way?

As others have pointed out, changing any part of the compiler, other
than as directed in its user manual, is not something a beginner
should do, or even contemplate.  Even simple changes to the TI header
could have unintended consequences.  

As Spiros suggested, defining the macro in every source and TI header
file that includes string.h, directly or indirectly, is the safest
approach.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#107880

Barry Schwarz says...

 > The above conditional compilation is LCC's way of
 > acknowledging that everything in that block is an
 > extension to the language as defined by the standard.
 > If you need any of those extensions, then you do not
 > define the macro __ANSI__ONLY__.  If you don't want the
 > LCC extensions, then you do define that macro.

 > Since your project was not originally created with LCC,
 > it seems very likely that you do not need any of LCC's
 > extensions.  In that case, it would make sense to define
 > the macro.

 > This completely ignores the question of whether the
 > original code required any Microsoft-unique compiler
 > features.  This includes extensions and compiler
 > eccentricities.  For example, the code may depend on
 > long and int being the same size or size_t being an
 > unsigned int.

Doesn't it also raise the question of whether just defining
the macro might cause the program to behave differently even
if it successfully compiles?  In other words, if TI had
included the macro originally, would the code still work the
way it does?  I guess I don't understand whether ANSIC__ONLY
just limits the functions that can be called, or whether it
changes behavior (like long vs int as you described).

Anyway, the idea is that by defining the macro, I can
otherwise leave TI's code the way it is, and leave LCC's
string.h the way it is, but eliminate the error.

 > Even if the code uses only standard features, there are
 > additional potential issues due to the evolution of the
 > standard over the years. For example, it used to be
 > permitted to omit the return type in a function
 > declaration and the compiler was required to assume the
 > type was int.  This is now a constraint violation.

 > The bottom line is merely getting a clean compile should
 > be only the first step before attempting any
 > modifications.  You also need to verify that the newly
 > compiled program behaves reasonably similar to the
 > original program.

The program does lots of different things, and I don't
really have a way to test all of them because I don't have
the chips they apply to.  Actually, I don't even understand
all of them.  So you're saying that I would have to find the
same version of Visual C that was used originally, which I
don't think I know unless it's in the exe somewhere, to be
sure that it behaves the same.

 > As Spiros suggested, defining the macro in every source
 > and TI header file that includes string.h, directly or
 > indirectly, is the safest approach.

Ok.

[toc] | [prev] | [next] | [standalone]

#107891

On 04/08/2017 02:04 PM, Peabody wrote:
> Barry Schwarz says...
> 
>  > The above conditional compilation is LCC's way of
>  > acknowledging that everything in that block is an
>  > extension to the language as defined by the standard.
>  > If you need any of those extensions, then you do not
>  > define the macro __ANSI__ONLY__.  If you don't want the
>  > LCC extensions, then you do define that macro.
...
> Doesn't it also raise the question of whether just defining
> the macro might cause the program to behave differently even
> if it successfully compiles?

Yes. That macro has a well-defined meaning for LCC - in principle, it
might have a completely different meaning (or none at all) when using
any other compiler (though with this particular name, it's unlikely to
do something completely different). Therefore, don't #define the macro
unless you first check the LCC documentation to verify what it means.

In general, turning ON C compliance should not be something done in your
code. My experience with other compilers (I have none with LCC itself)
suggests that LCC might automatically #define __ANSI_ONLY__ if you
choose the right command line option, so you don't need to #define it
yourself. Read the documentation for LCC to find out. -ansi is a popular
name for an option that turns on ANSI conformance.

> ...  In other words, if TI had
> included the macro originally, would the code still work the
> way it does?

It's quite likely that TI used a compiler that either didn't pay any
attention to __ANSI_ONLY__, or which automatically pre-#defines it when
appropriate options are selected. Either way, explicitly #defining it
would probably not have had an affect on the compiler they were using.


> ... I guess I don't understand whether ANSIC__ONLY
> just limits the functions that can be called, or whether it
> changes behavior (like long vs int as you described).

The only way to be sure is to read the LCC documentation. It's not a
general feature of C, it's compiler-specific.

> Anyway, the idea is that by defining the macro, I can
> otherwise leave TI's code the way it is, and leave LCC's
> string.h the way it is, but eliminate the error.

That would work, but I recommend removing the spurious declaration
instead. If it isn't actually being used, removing it is harmless. If it
is being used, removing it is a quick and simple way of finding out
where it's being used - doing so will almost certainly trigger an error
message if it is, in fact, being used.

...
>  > The bottom line is merely getting a clean compile should
>  > be only the first step before attempting any
>  > modifications.  You also need to verify that the newly
>  > compiled program behaves reasonably similar to the
>  > original program.
> 
> The program does lots of different things, and I don't
> really have a way to test all of them because I don't have
> the chips they apply to.

You only need to test the parts you plan to use.

> ...  Actually, I don't even understand
> all of them.  So you're saying that I would have to find the
> same version of Visual C that was used originally, which I
> don't think I know unless it's in the exe somewhere, to be
> sure that it behaves the same.

That would help, if it's easy to arrange. If not, you'll just have to
try it and see whether it works as intended.

[toc] | [prev] | [next] | [standalone]

#107894

On Sat, 8 Apr 2017 15:33:07 -0400
James Kuyper <jameskuyper@verizon.net> wrote:
> On 04/08/2017 02:04 PM, Peabody wrote:
> > Anyway, the idea is that by defining the macro, I can
> > otherwise leave TI's code the way it is, and leave LCC's
> > string.h the way it is, but eliminate the error.
> 
> That would work, but I recommend removing the spurious declaration
> instead. If it isn't actually being used, removing it is harmless. If it
> is being used, removing it is a quick and simple way of finding out
> where it's being used - doing so will almost certainly trigger an error
> message if it is, in fact, being used.

Whichever option he chooses , he should add a comment in the code. I've been
meaning to say this and kept forgetting.

> > The program does lots of different things, and I don't
> > really have a way to test all of them because I don't have
> > the chips they apply to.
> 
> You only need to test the parts you plan to use.
> 
> > ...  Actually, I don't even understand
> > all of them.  So you're saying that I would have to find the
> > same version of Visual C that was used originally, which I
> > don't think I know unless it's in the exe somewhere, to be
> > sure that it behaves the same.
> 
> That would help, if it's easy to arrange. If not, you'll just have to
> try it and see whether it works as intended.

I don't think that relying on a specific version of a specific compiler is
serviceable in the long run. If the code relies on a specific compiler better
to find this out sooner than later.

-- 
What will the successor of the ipod be called ? Bipod !

[toc] | [prev] | [next] | [standalone]

#107899

James Kuyper says...

 > In general, turning ON C compliance should not be
 > something done in your code. My experience with other
 > compilers (I have none with LCC itself) suggests that
 > LCC might automatically #define __ANSI_ONLY__ if you
 > choose the right command line option, so you don't need
 > to #define it yourself. Read the documentation for LCC
 > to find out. -ansi is a popular name for an option that
 > turns on ANSI conformance.

In LCC each project has configuration settings that include
the option to use ANSI-C only.  I haven't checked that box.
But it might be interesting to see whether the exe differs
in any way if that box is checked or not.

 >> So you're saying that I would have to find the same
 >> version of Visual C that was used originally, which I
 >> don't think I know unless it's in the exe somewhere, to
 >> be sure that it behaves the same.

 > That would help, if it's easy to arrange. If not, you'll
 > just have to try it and see whether it works as
 > intended.

Since they had no use in LCC, I've ignored four files
included in the TI source code, with these extensions:

.ncb
.opt
.DSP
.dsw

And the .DSP starts with these lines:

# Microsoft Developer Studio Project File - Name="BSLDEMO" - Package 
Owner=<4>
# Microsoft Developer Studio Generated Build File, Format Version 6.00

With one exception, all of the source files, including the
ones with the extensions listed above, are dated 2001-2006.
The exception is BSLDEMO.C, which includes the MAIN, and
it's dated 2/6/2013.  The exe is also dated that day.  But I
think version 6 of Visual Studio goes back to the earlier
period.  However, the .DSP file which refers to version 6
was last chnaged in 2006.  I guess there's no way to tell
what they actually used to compile the exe ni 2013.  I looked
through it with my hex editor, and saw nothing about that.

 

[toc] | [prev] | [next] | [standalone]

#107908

Barry Schwarz <schwarzb@dqel.com> writes:
[...]
> The above conditional compilation is LCC's way of acknowledging that
> everything in that block is an extension to the language as defined by
> the standard.  If you need any of those extensions, then you do not
> define the macro __ANSI__ONLY__.  If you don't want the LCC
> extensions, then you do define that macro.
>
> Since your project was not originally created with LCC, it seems very
> likely that you do not need any of LCC's extensions.  In that case, it
> would make sense to define the macro.
[...]

It's likely that such a macro would be predefined by the compiler in
response to a command-line option, one that causes it to (attempt to)
conform to a particular edition of the C standard.  I recall that
lcc-win has a "-ansic" option; I don't know whether its predecessor
LCC has the same option.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#107875

On 08/04/2017 14:07, Peabody wrote:

> There are no other instances of "strtrim" appearing anywhere in the TI
> source code.
>
> It seems that the safest way to deal with this might be to make a copy of
> string.h with the strtrim declaration commented out, and move it up to
> the source code folder, and change all <string.h> #includes to
> "string.h".  Would that work?  Is there a better way?
>
> I would appreciate any suggestions.

You can try just commenting out the strtrim declaration in TI_TXT_Files.h.

If there is a problem, then it might show up when building the project.

(I downloaded the files for BSLDEMO from github, and making that change 
made it compile under lccwin, which is the only compiler where it was a 
problem. Other C compilers (excluding one or two such as clang which I 
wasn't able to run for technical reasons) didn't care about it.

But I don't know how to build or run the project.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#107881

bartc says...

 > (I downloaded the files for BSLDEMO from github, and
 > making that change made it compile under lccwin, which
 > is the only compiler where it was a problem. Other C
 > compilers (excluding one or two such as clang which I
 > wasn't able to run for technical reasons) didn't care
 > about it.

 > But I don't know how to build or run the project.)

I appreciate your doing that.  I think the version on github
was done by FlyingCampDesign for the hardware interface they
sell to do this flashing. And they did exactly what I need
to do, except that they reversed the polarity of both DTR
and RTS, and exchanged their functions.  So the same idea,
but no cigar.

It's comforting that it compiled under the other compilers.
As far as the build is concerned, in LCC all I know to do is
click on Make at the top of the Compile tab, and somehow it
miraculously crates a Make and runs it.  I would be in deep
doodoo if it didn't do that.

What I'm having trouble dealing with is that unlike the
low-level assembly code I deal with with these
microprocessors, in C, and particularly with different
compilers, there's no way to just compare two versions and
see where they differ.  I strongly suspect, for example,
that the changes I want to make could be accomplished by
changing exactly two bytes, or maybe words, in the
original exe.  But I have no way to find them.  I can easily
find the differences between the TI source code and the FCD
source code.  But I can't compare the exe's and do that -
they're not even anywhere near the same size files - maybe
one has the debug stuff, and the other not, or optimization.

[toc] | [prev] | [next] | [standalone]

#107925

On 08/04/17 15:07, Peabody wrote:
> As will shortly be obvious, I'm completely new to C.  I'm trying to
> modify and recompile a Texas Instruments program called BSLDEMO2.exe
> which is used to flash new firmware to some of their MSP430
> microprocessors using a boot-strap loader. I need to invert the DTR line.
> They provide the source code, which they compiled using a Microsoft
> compiler.  I'm using LCC.  And this is C, not C++.
>

For a completely different solution, you could look at the Python BSD 
program.  It has been a while since I used it myself, but its immediate 
advantages for you over the C code here are:

1. It is in Python, not C, so making a small change is easy.  It is far 
easier to make a small change in a Python program when you don't know 
Python, than a small change in a C program when you don't know C.

2. It already supports inverting the DTR line.

<http://processors.wiki.ti.com/index.php/Open_Source_Projects_-_MSP430#Python_BSL_Module> 

[toc] | [prev] | [next] | [standalone]

#107929

David Brown says...

 > For a completely different solution, you could look at
 > the Python BSD program.  It has been a while since I
 > used it myself, but its immediate advantages for you
 > over the C code here are:

 > 1. It is in Python, not C, so making a small change is
 > easy.  It is far easier to make a small change in a
 > Python program when you don't know Python, than a small
 > change in a C program when you don't know C.

 > 2. It already supports inverting the DTR line.

 > <http://processors.wiki.ti.com/index.php/Open_Source_Pro
 > jects_-_MSP430#Pytho n_BSL_Module>

Yes, I saw that.  But whatever I end up with may be used by
other civilians like me who don't necessarily have Python
installed on their computers.  Or Java.

They will have to have a USB-to-Serial driver installed, but
otherwise just the exe.

[toc] | [prev] | [next] | [standalone]

#107941

On 09/04/17 14:52, Peabody wrote:
> David Brown says...
>
>  > For a completely different solution, you could look at
>  > the Python BSD program.  It has been a while since I
>  > used it myself, but its immediate advantages for you
>  > over the C code here are:
>
>  > 1. It is in Python, not C, so making a small change is
>  > easy.  It is far easier to make a small change in a
>  > Python program when you don't know Python, than a small
>  > change in a C program when you don't know C.
>
>  > 2. It already supports inverting the DTR line.
>
>  > <http://processors.wiki.ti.com/index.php/Open_Source_Pro
>  > jects_-_MSP430#Pytho n_BSL_Module>
>
> Yes, I saw that.  But whatever I end up with may be used by
> other civilians like me who don't necessarily have Python
> installed on their computers.  Or Java.
>

Java always seems makes life more complicated - people have to have the 
right Java versions installed.  I don't know why you bring that up here 
- there may be Java implementations of the BSL protocol, but Java is not 
any easier than C for making quick modifications.

But it's usually a very simple matter to install Python.  I don't know 
if you are interested only in Windows here, or also Linux - but any 
Linux system will have Python already.  And if you want to make a 
standalone exe file from Python, there are plenty of tools for that. 
"py2exe" will combine your Python code with the minimal Python libraries 
needed to interpret it.  I have used the msp430 BSL Python code along 
with my own project-specific Python code, and packaged it up as an exe 
file for Windows users - it is typically a couple of MB.

I find C an excellent language for its purpose - and use it extensively 
at work (such as for programming msp430 devices).  But for a task such 
as this, involving reading, parsing and manipulating text files such as 
the program files here, a high level language makes life much, much easier.


> They will have to have a USB-to-Serial driver installed, but
> otherwise just the exe.
>
>

[toc] | [prev] | [next] | [standalone]

#107964

David Brown says...

 > I find C an excellent language for its purpose - and use
 > it extensively at work (such as for programming msp430
 > devices).  But for a task such as this, involving
 > reading, parsing and manipulating text files such as the
 > program files here, a high level language makes life
 > much, much easier.

The problem is that I just told you everything I know about
the Windows API.  But Silabs, the maker of the CP2102 that
I'm using, has an excellent app note containing all the
calls needed to deal with COM ports in Windows.  And it's
all in C.  Without that, I would have been dead in the
water.

So I went looking for a small, hopefully simple, C compiler,
and found LCC.  I could essentially copy and paste all the
serial port stuff from the AN, but I had to do the file
handling and flashing stuff myself.  It's been like pulling
teeth, and all the problems came from not knowing the
format, grammar and structure of C.

But now I'm going to do what General Westmoreland should
have done in Viet Nam - declare victory and withdraw.  The
program is finished, and it works.  And I was able to
include parsing of both Intel-Hex and TI-TXT formats, which
took me a good part of today, what with my adventures with
sscanf.

I really appreciate everyone's comments and suggestions
here.  I hope I haven't been too much of a pest  Now I need
to write up a long-winded PDF about this, then figure out
where to post all of it online, which I'm sure will be yet
another execise in frustration because I just told you
everything I know about Git.
  
One thing: sscanf does not really work right, at least in
LCC.  Well I probably did something wrong, but in the end I
gave up on it and wrote my own ASCII-hex to binary code,
which works perfectly (so long as they don't use lower
case).  :-)

The file is 41K, and that's with no debug stuff included.  I
didn't optimize.  Don't know what that would do, but it's
already plenty fast, and, you know, 41K.

[toc] | [prev] | [next] | [standalone]

#107974

On 04/09/2017 07:20 PM, Peabody wrote:
...
> One thing: sscanf does not really work right, at least in
> LCC.  Well I probably did something wrong, ...

That's almost certainly the case. I'm not saying that their
implementation of sscanf() is perfect - it's just that at your current
level of C experience, a mistake on your part is much more likely than a
mistake on the part of the library implementor.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web