From: SourceForge.net <no...@so...> - 2008-02-26 02:11:28
|
Bugs item #1901818, was opened at 2008-02-26 13:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bill Teluk (ozzybill) Assigned to: Nobody/Anonymous (nobody) Summary: sprintf printing nulls In precision strings Initial Comment: sprintf does not behave as per spec when using it to print a string where the precision has been specified. What happens is that sprintf prints a null character after it prints the specified number of maximum characters. The source string did not have a null character at the index equivalent to the precision, therefore sprintf must have added it in. Problem was found when printing multiple sections into a destination string using sprintf - the last printed section inserted a null character. The (POSIX) spec indicates that no nulls from the source are printed. In the code sample below, a test string is written part way through a string array. Another string is then written at the start of the same array so that it's end coincides with the start of the second string. When printed to output, the expected output is "string1string2", but instead, "string1" is received, indicating that a null terminator was printed despite the printf precision specifying a maximum of 7 characters. /* BEGIN CODE SAMPLE */ /* sprintfbug.c */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]){ char strTarget[100]; sprintf(&strTarget[7],"%s","string2"); strTarget[14]=0; // Null terminator sprintf(strTarget,"%.7s","string1"); printf("String looks like:\n[%s]\n",strTarget); if( strTarget[7] == 0 ) printf("Found null terminator at index 7\n"); else printf("Did not find null terminator at index 7\n"); } /* END CODE SAMPLE */ VERSION INFORMATION Windows XP SP2 gcc -v Reading specs from ../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) ld -v GNU ld version 2.17.50 20060824 MinGW-5.1.3.exe Build Environ: just MinGW Gnu C compiler. #define __MINGW32_VERSION 3.13 #define __W32API_VERSION 3.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-02-26 04:13:52
|
Bugs item #1901818, was opened at 2008-02-25 21:11 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Waiting User Response >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Bill Teluk (ozzybill) Assigned to: Nobody/Anonymous (nobody) Summary: sprintf printing nulls In precision strings Initial Comment: sprintf does not behave as per spec when using it to print a string where the precision has been specified. What happens is that sprintf prints a null character after it prints the specified number of maximum characters. The source string did not have a null character at the index equivalent to the precision, therefore sprintf must have added it in. Problem was found when printing multiple sections into a destination string using sprintf - the last printed section inserted a null character. The (POSIX) spec indicates that no nulls from the source are printed. In the code sample below, a test string is written part way through a string array. Another string is then written at the start of the same array so that it's end coincides with the start of the second string. When printed to output, the expected output is "string1string2", but instead, "string1" is received, indicating that a null terminator was printed despite the printf precision specifying a maximum of 7 characters. /* BEGIN CODE SAMPLE */ /* sprintfbug.c */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]){ char strTarget[100]; sprintf(&strTarget[7],"%s","string2"); strTarget[14]=0; // Null terminator sprintf(strTarget,"%.7s","string1"); printf("String looks like:\n[%s]\n",strTarget); if( strTarget[7] == 0 ) printf("Found null terminator at index 7\n"); else printf("Did not find null terminator at index 7\n"); } /* END CODE SAMPLE */ VERSION INFORMATION Windows XP SP2 gcc -v Reading specs from ../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) ld -v GNU ld version 2.17.50 20060824 MinGW-5.1.3.exe Build Environ: just MinGW Gnu C compiler. #define __MINGW32_VERSION 3.13 #define __W32API_VERSION 3.10 ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2008-02-25 23:13 Message: Logged In: YES user_id=15438 Originator: NO <blockquote>The (POSIX) spec indicates that no nulls from the source are printed.</blockquote> This is windows. What does Microsoft Documentation say? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-02-26 06:28:56
|
Bugs item #1901818, was opened at 2008-02-26 13:11 Message generated for change (Comment added) made by ozzybill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Waiting User Response >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bill Teluk (ozzybill) Assigned to: Nobody/Anonymous (nobody) Summary: sprintf printing nulls In precision strings Initial Comment: sprintf does not behave as per spec when using it to print a string where the precision has been specified. What happens is that sprintf prints a null character after it prints the specified number of maximum characters. The source string did not have a null character at the index equivalent to the precision, therefore sprintf must have added it in. Problem was found when printing multiple sections into a destination string using sprintf - the last printed section inserted a null character. The (POSIX) spec indicates that no nulls from the source are printed. In the code sample below, a test string is written part way through a string array. Another string is then written at the start of the same array so that it's end coincides with the start of the second string. When printed to output, the expected output is "string1string2", but instead, "string1" is received, indicating that a null terminator was printed despite the printf precision specifying a maximum of 7 characters. /* BEGIN CODE SAMPLE */ /* sprintfbug.c */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]){ char strTarget[100]; sprintf(&strTarget[7],"%s","string2"); strTarget[14]=0; // Null terminator sprintf(strTarget,"%.7s","string1"); printf("String looks like:\n[%s]\n",strTarget); if( strTarget[7] == 0 ) printf("Found null terminator at index 7\n"); else printf("Did not find null terminator at index 7\n"); } /* END CODE SAMPLE */ VERSION INFORMATION Windows XP SP2 gcc -v Reading specs from ../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) ld -v GNU ld version 2.17.50 20060824 MinGW-5.1.3.exe Build Environ: just MinGW Gnu C compiler. #define __MINGW32_VERSION 3.13 #define __W32API_VERSION 3.10 ---------------------------------------------------------------------- >Comment By: Bill Teluk (ozzybill) Date: 2008-02-26 17:28 Message: Logged In: YES user_id=1432992 Originator: YES According to MSDN C/C++ documentation (at http://msdn2.microsoft.com/en-us/library/0ecbz014(VS.80).aspx ) Section "How Precision Values Affect Type", states that for the "s" Type: "The precision specifies the maximum number of characters to be printed. Characters in excess of precision are not printed." In my sample code, there is one extra character printed eg. the null character, eg. that's one character more than the precision specification in the sample code. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-02-26 15:13 Message: Logged In: YES user_id=15438 Originator: NO <blockquote>The (POSIX) spec indicates that no nulls from the source are printed.</blockquote> This is windows. What does Microsoft Documentation say? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-02-26 12:42:26
|
Bugs item #1901818, was opened at 2008-02-25 21:11 Message generated for change (Settings changed) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Known bugs >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Bill Teluk (ozzybill) Assigned to: Nobody/Anonymous (nobody) Summary: sprintf printing nulls In precision strings Initial Comment: sprintf does not behave as per spec when using it to print a string where the precision has been specified. What happens is that sprintf prints a null character after it prints the specified number of maximum characters. The source string did not have a null character at the index equivalent to the precision, therefore sprintf must have added it in. Problem was found when printing multiple sections into a destination string using sprintf - the last printed section inserted a null character. The (POSIX) spec indicates that no nulls from the source are printed. In the code sample below, a test string is written part way through a string array. Another string is then written at the start of the same array so that it's end coincides with the start of the second string. When printed to output, the expected output is "string1string2", but instead, "string1" is received, indicating that a null terminator was printed despite the printf precision specifying a maximum of 7 characters. /* BEGIN CODE SAMPLE */ /* sprintfbug.c */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]){ char strTarget[100]; sprintf(&strTarget[7],"%s","string2"); strTarget[14]=0; // Null terminator sprintf(strTarget,"%.7s","string1"); printf("String looks like:\n[%s]\n",strTarget); if( strTarget[7] == 0 ) printf("Found null terminator at index 7\n"); else printf("Did not find null terminator at index 7\n"); } /* END CODE SAMPLE */ VERSION INFORMATION Windows XP SP2 gcc -v Reading specs from ../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) ld -v GNU ld version 2.17.50 20060824 MinGW-5.1.3.exe Build Environ: just MinGW Gnu C compiler. #define __MINGW32_VERSION 3.13 #define __W32API_VERSION 3.10 ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2008-02-26 07:42 Message: Logged In: YES user_id=15438 Originator: NO Your bug should be reported to Microsoft since they are the implementors of this function which is found in MSVCRT.DLL. ---------------------------------------------------------------------- Comment By: Bill Teluk (ozzybill) Date: 2008-02-26 01:28 Message: Logged In: YES user_id=1432992 Originator: YES According to MSDN C/C++ documentation (at http://msdn2.microsoft.com/en-us/library/0ecbz014(VS.80).aspx ) Section "How Precision Values Affect Type", states that for the "s" Type: "The precision specifies the maximum number of characters to be printed. Characters in excess of precision are not printed." In my sample code, there is one extra character printed eg. the null character, eg. that's one character more than the precision specification in the sample code. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-02-25 23:13 Message: Logged In: YES user_id=15438 Originator: NO <blockquote>The (POSIX) spec indicates that no nulls from the source are printed.</blockquote> This is windows. What does Microsoft Documentation say? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-02-28 13:35:03
|
Bugs item #1901818, was opened at 2008-02-26 02:11 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Behaves as Documented Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Bill Teluk (ozzybill) Assigned to: Nobody/Anonymous (nobody) Summary: sprintf printing nulls In precision strings Initial Comment: sprintf does not behave as per spec when using it to print a string where the precision has been specified. What happens is that sprintf prints a null character after it prints the specified number of maximum characters. The source string did not have a null character at the index equivalent to the precision, therefore sprintf must have added it in. Problem was found when printing multiple sections into a destination string using sprintf - the last printed section inserted a null character. The (POSIX) spec indicates that no nulls from the source are printed. In the code sample below, a test string is written part way through a string array. Another string is then written at the start of the same array so that it's end coincides with the start of the second string. When printed to output, the expected output is "string1string2", but instead, "string1" is received, indicating that a null terminator was printed despite the printf precision specifying a maximum of 7 characters. /* BEGIN CODE SAMPLE */ /* sprintfbug.c */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]){ char strTarget[100]; sprintf(&strTarget[7],"%s","string2"); strTarget[14]=0; // Null terminator sprintf(strTarget,"%.7s","string1"); printf("String looks like:\n[%s]\n",strTarget); if( strTarget[7] == 0 ) printf("Found null terminator at index 7\n"); else printf("Did not find null terminator at index 7\n"); } /* END CODE SAMPLE */ VERSION INFORMATION Windows XP SP2 gcc -v Reading specs from ../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) ld -v GNU ld version 2.17.50 20060824 MinGW-5.1.3.exe Build Environ: just MinGW Gnu C compiler. #define __MINGW32_VERSION 3.13 #define __W32API_VERSION 3.10 ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2008-02-28 13:34 Message: Logged In: YES user_id=823908 Originator: NO Hmm. I don't believe this is a bug at all! The test case given uses the `sprintf()' function, which *always* adds a terminating NUL at the end of the output record; this is irrespective of any precision assigned to individual fields within the record. According to IEEE-1003.2 (POSIX): | int sprintf(char *restrict s, const char *restrict format, ...); | | The sprintf() function shall place output followed by the null byte, '\0', | in consecutive bytes starting at *s; it is the user's responsibility to | ensure that enough space is available. That's *exactly* what the test case is doing; your expectations simply are not consistent with the specified correct behaviour, and the "%.7s" format specification is immaterial. You *may* be able to achieve the behaviour you expect, if you substitute MSVCRT's `_snprintf()' function, for your second use of `sprintf()', but even this non-POSIX conforming implementation may not do what you want; with a truly POSIX conforming implementation, even if you substitute `snprintf()' for your second `sprintf()' the behaviour your test case exhibits is correct, as per specification -- both `sprintf()' and `snprintf()' are required to append a terminating NUL to each record written, and with `snprintf()', the specified buffer length must be one greater than the number of non-NUL characters to be written. The only standards conforming way to achieve your objective, other than by executing the `sprintf()' calls in strictly left to right order of the output strings, is to substitute `strncpy()' or `memcpy()' for your second `snprintf()' call. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-02-26 12:42 Message: Logged In: YES user_id=15438 Originator: NO Your bug should be reported to Microsoft since they are the implementors of this function which is found in MSVCRT.DLL. ---------------------------------------------------------------------- Comment By: Bill Teluk (ozzybill) Date: 2008-02-26 06:28 Message: Logged In: YES user_id=1432992 Originator: YES According to MSDN C/C++ documentation (at http://msdn2.microsoft.com/en-us/library/0ecbz014(VS.80).aspx ) Section "How Precision Values Affect Type", states that for the "s" Type: "The precision specifies the maximum number of characters to be printed. Characters in excess of precision are not printed." In my sample code, there is one extra character printed eg. the null character, eg. that's one character more than the precision specification in the sample code. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-02-26 04:13 Message: Logged In: YES user_id=15438 Originator: NO <blockquote>The (POSIX) spec indicates that no nulls from the source are printed.</blockquote> This is windows. What does Microsoft Documentation say? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 |
From: SourceForge.net <no...@so...> - 2008-02-28 14:08:52
|
Bugs item #1901818, was opened at 2008-02-26 02:11 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Behaves as Documented Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Bill Teluk (ozzybill) Assigned to: Nobody/Anonymous (nobody) Summary: sprintf printing nulls In precision strings Initial Comment: sprintf does not behave as per spec when using it to print a string where the precision has been specified. What happens is that sprintf prints a null character after it prints the specified number of maximum characters. The source string did not have a null character at the index equivalent to the precision, therefore sprintf must have added it in. Problem was found when printing multiple sections into a destination string using sprintf - the last printed section inserted a null character. The (POSIX) spec indicates that no nulls from the source are printed. In the code sample below, a test string is written part way through a string array. Another string is then written at the start of the same array so that it's end coincides with the start of the second string. When printed to output, the expected output is "string1string2", but instead, "string1" is received, indicating that a null terminator was printed despite the printf precision specifying a maximum of 7 characters. /* BEGIN CODE SAMPLE */ /* sprintfbug.c */ #include <stdio.h> #include <string.h> int main(int argc, char *argv[]){ char strTarget[100]; sprintf(&strTarget[7],"%s","string2"); strTarget[14]=0; // Null terminator sprintf(strTarget,"%.7s","string1"); printf("String looks like:\n[%s]\n",strTarget); if( strTarget[7] == 0 ) printf("Found null terminator at index 7\n"); else printf("Did not find null terminator at index 7\n"); } /* END CODE SAMPLE */ VERSION INFORMATION Windows XP SP2 gcc -v Reading specs from ../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as - -host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync hronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) ld -v GNU ld version 2.17.50 20060824 MinGW-5.1.3.exe Build Environ: just MinGW Gnu C compiler. #define __MINGW32_VERSION 3.13 #define __W32API_VERSION 3.10 ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2008-02-28 14:08 Message: Logged In: YES user_id=823908 Originator: NO Please excuse typo: s/IEEE-1003.2/IEEE-1003.1/ ---------------------------------------------------------------------- Comment By: Keith Marshall (keithmarshall) Date: 2008-02-28 13:34 Message: Logged In: YES user_id=823908 Originator: NO Hmm. I don't believe this is a bug at all! The test case given uses the `sprintf()' function, which *always* adds a terminating NUL at the end of the output record; this is irrespective of any precision assigned to individual fields within the record. According to IEEE-1003.2 (POSIX): | int sprintf(char *restrict s, const char *restrict format, ...); | | The sprintf() function shall place output followed by the null byte, '\0', | in consecutive bytes starting at *s; it is the user's responsibility to | ensure that enough space is available. That's *exactly* what the test case is doing; your expectations simply are not consistent with the specified correct behaviour, and the "%.7s" format specification is immaterial. You *may* be able to achieve the behaviour you expect, if you substitute MSVCRT's `_snprintf()' function, for your second use of `sprintf()', but even this non-POSIX conforming implementation may not do what you want; with a truly POSIX conforming implementation, even if you substitute `snprintf()' for your second `sprintf()' the behaviour your test case exhibits is correct, as per specification -- both `sprintf()' and `snprintf()' are required to append a terminating NUL to each record written, and with `snprintf()', the specified buffer length must be one greater than the number of non-NUL characters to be written. The only standards conforming way to achieve your objective, other than by executing the `sprintf()' calls in strictly left to right order of the output strings, is to substitute `strncpy()' or `memcpy()' for your second `snprintf()' call. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-02-26 12:42 Message: Logged In: YES user_id=15438 Originator: NO Your bug should be reported to Microsoft since they are the implementors of this function which is found in MSVCRT.DLL. ---------------------------------------------------------------------- Comment By: Bill Teluk (ozzybill) Date: 2008-02-26 06:28 Message: Logged In: YES user_id=1432992 Originator: YES According to MSDN C/C++ documentation (at http://msdn2.microsoft.com/en-us/library/0ecbz014(VS.80).aspx ) Section "How Precision Values Affect Type", states that for the "s" Type: "The precision specifies the maximum number of characters to be printed. Characters in excess of precision are not printed." In my sample code, there is one extra character printed eg. the null character, eg. that's one character more than the precision specification in the sample code. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2008-02-26 04:13 Message: Logged In: YES user_id=15438 Originator: NO <blockquote>The (POSIX) spec indicates that no nulls from the source are printed.</blockquote> This is windows. What does Microsoft Documentation say? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1901818&group_id=2435 |