This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/EK-TM4C129EXL: atol.c returns 0 for decimal 1

Guru 54087 points
Part Number: EK-TM4C129EXL

Tool/software: TI C/C++ Compiler

Why is atol.c not returning an integer 1 for decimal 1, always returned as 0?

Other oddity being return argument value of the call header is always the cell number of the array[6] being loaded in the command. The returned argument in the function header does not contain the trailing Boolean switch following directly behind the matched command in cell 6 so we must pluck it out inside the function as shown below. The Boolean switch is changing from 0 to 1 as CCS debug confirms but atol() returns any decimal 1 as integer 0. I don't see atol() do that in another command where more than 1 digit follows a command. The atol function has not been updated since 1993.  

  • The function atol returns a correct result for this input.

    The first byte in the input string st is not an ASCII character, but the binary value 1.  On line 46, the value 1 does not correspond to any ASCII space characters, so st does not advance.  On line 48, *st is assigned to cp, thus cp now contains the binary value 1.  Since cp does not contain the ASCII values for the characters + or -, sign is set to 0 and st does not advance.  On line 51, cp does not correspond to any ASCII values for digits, so the while loop does 0 iterations.  This means the variable result, which is initialized to 0 on line 42, never changes.  Line 58 does not change result, and line 59 returns result.

    I get lost trying to understand the rest of the code.  So I cannot explain why a string which starts with the binary value 1 is passed to atol.  But I see no reason to suspect the compiler made an error.

    Thanks and regards,

    -George

  • Some confusion on your part being It is not ASCII input to atoll(), it is hexadecimal 0x01 digit (_N_) values defined by macro of (ctype.h) below. The input is alpha followed by decimal digits. The alpha part of the command is being handled by defined struct via NULL termination list. For some reason the *argv[] header of the command never has the array[6] value since it was sent after the command string was called, trailing behind it. Oddly single stepping the command the array[6] value 1 was always present but was being skipped by (if(sw01) test and always fell through to (if(!sw01).  

    If we REM line 54 often both 1 and 0 is returned the first few times, there after it only returns 1 even when g_ppcArgv[6] = 0. Why would line 54 ever subtract '0' (0x30) from the result?  The while(_isdigit cp) loop is bouncing rapidly for F8, often skips right over the command test when '0' is returned value.

    /************************************************************************/
    /************************************************************************/
    /*  MACRO DEFINITIONS                                                   */
    /************************************************************************/
    #define _U_   ((unsigned char)0x01)       /* upper case letter */
    #define _L_   ((unsigned char)0x02)       /* lower case letter */
    #define _N_   ((unsigned char)0x04)       /* digit             */
    #define _S_   ((unsigned char)0x08)       /* white space       */
    #define _P_   ((unsigned char)0x10)       /* punctuation       */
    #define _C_   ((unsigned char)0x20)       /* control chars     */
    #define _H_   ((unsigned char)0x40)       /* A-F, a-f and 0-9  */
    #define _B_   ((unsigned char)0x80)       /* blank             */
    
    #define _isalnum(a)  (_ctypes_[(a)+1] & (_U_ | _L_ | _N_))
    #define _isalpha(a)  (_ctypes_[(a)+1] & (_U_ | _L_))
    #define _iscntrl(a)  (_ctypes_[(a)+1] & _C_)
    #define _isdigit(a)  (_ctypes_[(a)+1] & _N_)
    #define _isgraph(a)  (_ctypes_[(a)+1] & (_U_ | _L_ | _N_ | _P_))
    #define _islower(a)  (_ctypes_[(a)+1] & _L_)
    #define _isprint(a)  (_ctypes_[(a)+1] & (_B_ | _U_ | _L_ | _N_ | _P_))
    #define _ispunct(a)  (_ctypes_[(a)+1] & _P_)
    #define _isspace(a)  (_ctypes_[(a)+1] & _S_)
    #define _isupper(a)  (_ctypes_[(a)+1] & _U_)
    #define _isxdigit(a) (_ctypes_[(a)+1] & _H_)

  • Hi George,

    After working with this issue in Saturday it was finally revealed the passing of long to character can not be returned outside the function header *st. The atoll() underlying instructions would not copy hexadecimal value from (cp) into result via (=) directive. After modifying atoll() several different ways, recompile C++ library source via (Cygwin), the same results during single stepping occur.

    The solution to recover specific array cell hex value; Pass the hex char into integer via the function header as atoi(viavar). Note the RAW hex byte could not be found in the (argc, argv[]) of the call back and should have been easily retrieved via the typedef struct (const char) pointer returned with the command of matching arguments array. It seems the construct of the defined typedef struct (const char) once again fails to transfer (ignores) hexadecimal characters should be present in the (argc, argv[]).

    Last I was aware hexadecimal numbers 0-9 are also decimal integers (0-9) characters ignore A-F base 16. The observation taken is the compiler is not producing correct Thumb instructions in this noted case above so result never contained the hex value from cp.