text:
Typical errors of porting C++ code on the 64-bit platform
Annotation. Program errors occurring while porting C++ code from 32-bit platforms on 64-bit ones are observed. Examples of the incorrect code and the ways to correct it are given. Methods and means of the code analysis which allow to diagnose the errors discussed, are listed.
This text is an abridged variant of "20 issues of porting C++ code on the 64-bit platform" article. If you are interested in the topic of porting programs to 64-bit systems, you can find a full version of the article here 20 issues of porting C++ code on the 64-bit platform.
We offer you to read the article devoted to the port of the program code of 32-bit applications on 64-bit systems. The article is written for programmers who use C++ but it may be also useful for all who face the port of applications on other platforms.
One should understand properly that the new class of errors which appears while writing 64-bit programs is not just some new incorrect constructions among thousands of others. These are inevitable difficulties which the developers of any developing program will face. This article will help you to be ready for these difficulties and will show the ways to overcome them. Besides advantages, any new technology (in programming and other spheres as well) carries some limitations and even problems of using this technology. The same situation can be found in the sphere of developing 64-bit software. We all know that 64-bit software is the next step of the information technologies development. But in reality, only few programmers have faced the nuances of this sphere and developing 64-bit programs in particular.
We won?t dwell on the advantages which the use of 64-bit architecture opens before programmers. There are a lot of publications devoted to this theme and the reader can find them easily.
The aim of this article is to observe thoroughly those problems which the developer of 64-bit programs can face. In the article you will learn about:
The aim of this article is to observe thoroughly those problems which the developer of 64-bit programs can face. In the article you will learn about:
The given information will allow you:
There are a lot of examples given in the article which you should try in the programming environment for better understanding. Going into them you will get something more than just an addition of separate elements. You will open the door into the world of 64-bit systems.
We'll use term "memsize" type in the text. By this we'll understand any simple integer type which is capable to keep a pointer and changes its size according to the change of the platform dimension form 32-bit to 64-bit. The examples memsize types: size_t, ptrdiff_t, all pointers, intptr_t, INT_PTR, DWORD_PTR.
We should say some words about the data models which determine the correspondence of the sizes of fundamental types for different systems. Table N1 contains data models which can interest us.
And finally, 64-bit model in Linux (LP64) differs from that in Windows (LLP64) only in the size of long type. So long as it is their only difference, to summarize the account we'll avoid using long, unsigned long types, and will use ptrdiff_t, size_t types.
Let's start observing the type errors which occur while porting programs on the 64-bit architecture.
1. Off-warnings.
In all books devoted to the development of the quality code it is recommended to set a warning level of warnings shown by the compiler on as high level as possible. But there are situations in practice when for some project parts there is a lower diagnosis level set or it is even set off. Usually it is very old code which is supported but not modified. Programmers who work over the project are used to that this code works and don't take its quality into consideration. Here it is a danger to miss serious warnings by the compiler while porting programs on the new 64-bit system.
While porting an application you should obligatory set on warnings for the whole project which help to check the compatibility of the code and analyze them thoroughly. It can help to save a lot of time while debugging the project on the new architecture.
If we won't do this the simplest and stupidest errors will occur in all their variety. Here it is a simple example of overflow which occurs in a 64-bit program if we ignore warnings at all.
unsigned char *array[50];
2. Use of the functions with a variable number of arguments.
The typical example is the incorrect use of printf, scanf functions and their variants:
1) const char *invalidFormat="%u";
2) char buf[9];
In the second case the author of the code didn't take into account that the pointer size may become more than 32-bit in future. As a result this code will cause the buffer overflow on the 64-bit architecture.
The incorrect use of functions with a variable number of arguments is a typical error on all the architectures, not only on 64-bit ones. This is related to the fundamental danger of the use of the given C++ language constructions. The common practice is to refuse them and use safe programming methods. We recommend you strongly to modify the code and use safe methods. For example, you may replace printf with cout, and sprintf with boost::format or std::stringstream.
If you have to support the code which uses functions of sscanf type, in the control lines format we can use special macros which open into necessary modifiers for different systems. An example:
// PR_SIZET on Win64=I"
3. Magic numbers
In the low-quality code there are often magic numbers the mere presence of which is dangerous. During the migration of the code on the 64-bit platform these magic numbers may make the code inefficient if they participate in operations of calculation of address, objects size or bit operations.
Table N2 contains basic magic numbers which may influence the workability of an application on a new platform.
Value Description
Let's look at some errors related to the use of magic numbers. The most frequent is a record of number values of type sizes.
1) size_t ArraySize=N * 4;
2) size_t values[ARRAY_SIZE];
3) size_t n, newexp;
1) size_t ArraySize=N * sizeof(intptr_t);
2) size_t values[ARRAY_SIZE];
3) size_t n, newexp;
// constant '1111..110000'
#ifdef _WIN64
#define INVALID_RESULT (0xFFFFFFFFu)
int a=-1; // 0xFFFFFFFFi32
Let's return to the error with INVALID_RESULT. The use of the number 0xFFFFFFFFu causes the failure of the execution of "len == (size_t)(-1)" condition in a 64-bit program. The best solution is to change the code in such a way that it doesn't need special marker values. If you cannot refuse them for some reason or think it unreasonable to correct the code fundamentally just use fair value -1.
#define INVALID_RESULT (size_t(-1))
4. Bit shifting operations.
Bit shifting operations can cause a lot of troubles during the port from the 32-bit system on the 64-bit one if used inattentively. Let's begin with an example of a function which defines the bit you've chosen as 1 in a variable of memsize type.
ptrdiff_t SetBitN(ptrdiff_t value, unsigned bitNum) {
Pay attention that "1" has int type and during the shift on 32 positions an overflow will occur. To correct the code it is necessary to make the constant "1" of the same type as the variable mask.
ptrdiff_t mask=ptrdiff_t(1) << bitNum;
5. Storing of pointer addresses.
A large number of errors during the migration on 64-bit systems are related to the change of a pointer size in relation to the size of usual integers. In the environment with the data ILP32 usual integers and pointers have the same size. Unfortunately the 32-bit code is based on this supposition everywhere. Pointers are often casted to int, unsigned int and other types improper to fulfill address calculations.
You should understand exactly that one should use only memsize types for integer pointers form. Preference should be given to uintptr_t type for it shows intentions more clearly and makes the code more portable saving it from changes in future
Let's look at two small examples.
1) char *p;
2) DWORD tmp=(DWORD)malloc(ArraySize);
1) char *p;
2) DWORD_PTR tmp=(DWORD_PTR)malloc(ArraySize);
The following code won't hide and will show up at the first execution.
void GetBufferAddr(void **retPtr) {
uintptr_t bufAddress;
In the end I'd like to mention that it will be a bad style to store the pointer address into types which are always equal 64-bits. One will have to correct the code shown further again when 128-bit systems will appear.
PVOID p;
6. Memsize types in unions.
The peculiarity of a union is that for all members of the union the same memory area is allocated that is they overlap. Although the access to this memory area is possible with the use of any of the elements the element for this aim should be chosen so that the result won't be senseless.
One should pay attention to the unions which contain pointers and other members of memsize type.
When there is a necessity to work with a pointer as an integer sometimes it is convenient to use the union as it is shown in the example, and work with the number form of the type without using explicit conversions.
union PtrNumUnion {
union PtrNumUnion {
union SizetToBytesUnion {
union SizetToBytesUnion {
7. Change of an array type
Sometimes it is necessary (or just convenient) in programs to present array items in the form of the elements of a different type. Dangerous and safe type conversions are shown in the following code.
int array[4]={ 1, 2, 3, 4 };
On the 64-bit system we got "2 17179869187" in the output for it is value 17179869187 which is situated in the first item of sizetPtr array. In some cases we need this very behavior but usually it is an error.
The correction of the described situation consists in the refuse of dangerous type conversions by modernizing the program. Another variant is to create a new array and copy values of the original one into it.
8. Virtual functions with arguments of memsize type
If there are big derived class graphs with virtual functions in your program, there is a risk to use inattentively arguments of different types but these types actually coincide on the 32-bit system. For example, in the base class you use size_t type as an argument of a virtual function and in the derived class type unsigned. So this code will be incorrect on the 64-bit system.
But an error like this doesn't necessarily hide in big derived class graphs and here it is one of the examples.
class CWinApp {
virtual void WinHelp(DWORD dwData, UINT nCmd=HELP_CONTEXT);
The correction consists in the use of the same types in the corresponding virtual functions.
class CSampleApp : public CWinApp {
9. Serialization and data exchange.
An important point during the port of a software solution on the new platform is succession to the existing data exchange protocol. It is necessary to provide the read of the existing projects formats, to carry out the data exchange between 32-bit and 64-bit processes etc.
Mostly the errors of this kind consist in the serialization of memsize types and data exchange operations using them.
1) size_t PixelCount;
2) __int32 value_1;
3) time_t time;
The use of types of volatile size.
It is unacceptably to use types which change their size depending on the development environment in binary interfaces of data exchange. In C++ language all the types don't have distinct sizes and consequently it is not possible to use them all for these aims. That's why the developers of the development means and programmers themselves develop data types which have an exact size such as __int8, __int16, INT32, word64 etc.
The use of such types provides data portability between programs on different platforms although it needs the use of odd ones. The three shown examples are written inaccurately and this will show up on the changing of the capacity of some data types from 32-bit to 64-bit. Taking into account the necessity to support old data formats the correction may look as follows.
1) size_t PixelCount;
2) __int32 value_1;
3) time_t time;
Ignoring of the byte order.
Even after the correction of volatile type sizes you may face the incompatibility of binary formats. The reason is a different data presentation. Most frequently it is related to a different byte order.
The byte order is a method of recording of bytes of multibyte numbers. The little-endian order means that the recording begins with the lowest byte and ends with the highest one. This record order was acceptable in the memory of PCs with x86-processors. The big-endian order - the recording begins with the highest byte and ends with the lowest one. This order is a standard for TCP/IP protocols. That's why the big-endian byte order is often called the network byte order. This byte order is used by processors Motorola 68000, SPARC.
While developing the binary interface or data format you should remember about the byte order. If the 64-bit system on which you are porting a 32-bit application has a different byte order you'll just have to take it into account in your code. For conversion between the big-endian byte order and the little-endian one you may use functions htonl(), htons(), bswap_64 etc.
10. Pointer address arithmetic.
The first example.
unsigned short a16, b16, c16;
One should take care to avoid possible overflows in pointer arithmetic. For this purpose it's better to use memsize types or the explicit type conversion in expressions which carry pointers. Using the explicit type conversion we can rewrite the code in the following way.
short a16, b16, c16;
int A=-2;
Then calculation of "ptr + 0xFFFFFFFFu" takes place but the result of it depends on the pointer size on the particular architecture. If addition will take place in a 32-bit program the given expression will be an equivalent of "ptr-1" and we'll successfully print number 3.
In a 64-bit program 0xFFFFFFFFu value will be added fairly to the pointer and the result will be that the pointer will be outbound of the array. And while getting access to the item of this pointer we'll face troubles.
To avoid the shown situation, as well as in the first case, we advise you to use only memsize types in pointer arithmetic. Here are two variants of the code correction:
ptr=ptr + (ptrdiff_t(A) + ptrdiff_t(B));
ptrdiff_t A=-2;
int A=-2;
11. Arrays indexing.
This kind of errors is separated from the others for better structuring of the account because indexing in arrays with the use of square brackets is just a different record of address arithmetic observed before.
In programming in language C and then C++ a practice formed to use in the constructions of the following kind variables of int/unsigned types:
unsigned Index=0;
The given code won't process in a 64-bit program an array containing more than UINT_MAX items. After the access to the item with UNIT_MAX index an overflow of the variable Index will occur and we'll get infinite loop.
To persuade you entirely in the necessity of using only memsize types for indexing and in the expressions of address arithmetic, I'll give the last example.
class Region {
Programmers often make a mistake trying to correct the code in the following way:
float Region::GetCell(int x, int y, int z) const {
If you want to correct the code without changing types of the variables participating in the expression you may use the explicit type conversion of every variable memsize type:
float Region::GetCell(int x, int y, int z) const {
typedef ptrdiff_t TCoord;
12. Mixed use of simple integer types and memsize types.
Mixed use of memsize and non-memsize types in expressions may cause incorrect results on 64-bit systems and be related to the change of the input values rate. Let's study some examples.
size_t Count=BigValue;
Another frequent error is a record of the expressions of the following kind:
int x, y, z;
Let's give an example of a small code which shows the danger of inaccurate expressions with mixed types (the results are got with the use Microsoft Visual C++ 2005, 64-bit compilation mode).
int x=100000;
intptr_t v2=intptr_t(x) * y * z;
The order of the calculation of an expression with operators of the same priority is not defined. To be more exact, the compiler can calculate sub-expressions in such an order which it considers to be more efficient even if sub-expressions cause (side effect). The order of the appearing of side effects is not defined. Expressions including communicative and association operations (*, +, &, |, ^), may be converted in a free way even if there are brackets. To assign the strict order of the calculation of the expression it is necessary to use the explicit temporary variable.
That's why if the result of the expression should be of memsize type, only memsize types must participate in the expression. The right variant:
Mixed use of types may occur in the change of the program logic.
ptrdiff_t val_1=-1;
If you need to return the previous behavior you should change the variable val_2 type.
ptrdiff_t val_1=-1;
13. Implicit type conversions while using functions.
Observing the previous kind of errors related to mixing of simple integer types and memsize types, we surveyed only simple expressions. But similar problems may occur while using other C++ constructions too.
extern int Width, Height, Depth;
extern int Width, Height, Depth;
extern char *begin, *end;
And here it is one more example but now we'll observe not the returned value but the formal function argument.
void foo(ptrdiff_t delta);
14. Overload functions.
During the port of 32-bit programs on the 64-bit platform the change of the logic of its work may be found which is related to the use of overload functions. If the function is overlapped for 32-bit and 64-bit values the access to it with the argument of memsize type will be compiled into different calls on different systems. This method may be useful as, for example, in the following code:
static size_t GetBitCount(const unsigned __int32 &) {
class MyStack {
We think you understand this kind of errors and that you should pay attention to the call of overload functions transferring actual arguments of memsize type.
15. Data alignment.
Processors work more efficiently when they deal with data aligned properly. As a rule the 32-bit data item must be aligned at the border multiple 4 bytes and the 64-bit item at the border 8 bytes. The try to work with unaligned data on processors IA-64 (Itanium) as it is shown in the following example, will cause exception.
#pragma pack (1) // Also set by key /Zp in MSVC
#pragma pack (1) // Also set by key /Zp in MSVC
On the architecture x64 during the access to unaligned data exception does not occur but you should avoid them either. Firstly, because of the essential slowing down of the speed of the access to these data, and secondly, because of a high probability of porting the program on the platform IA-64 in future.
Let's look at one more example of the code which does not take into account the data alignment.
struct MyPointersArray {
The correct calculation of the size should look as follows:
struct MyPointersArray {
Always use these macros to get a shift in the structure without relying on your knowledge of the sizes of types and the alignment. Here it is the example of the code with the correct calculation of the structure member address:
struct TFoo {
16. The use of outdated functions and predefined constants.
While developing a 64-bit application, be sure to bear in mind the changes of the environment in which it will be performed. Some functions will become outdated and it will be necessary to replace them with some variants. GetWindowLong is a good example of such function in the Windows operation system. Pay your attention to the constants referring to the interaction with the environment in which the program is functioning. In Windows the lines containing "system32" or "Program Files" will be suspect.
17. Explicit type conversions.
Be accurate with explicit type conversions. They may change the logic of the program execution when types change their capacity of cause the loss of significant bits. It is difficult to adduce typical examples of errors related to the explicit type conversion for they are very different and specific for different programs. You have become acquainted with some errors related to the explicit type conversion earlier.
Error diagnosis.
The diagnosis of the errors occurring while porting 32-bit programs on 64-bit systems is a difficult task. The port of a not very quality code written without taking into account peculiarities of other architectures, may demand a lot of time and efforts. That's why we'll pay some attention to the description of methods and means which may simplify this task.
Unit test.
Unit test have fought well-earned respect among programmers long ago. Unit tests will help to check the correctness of the program after the port on a new platform. But there is one nuance which you should keep in mind.
Unit test may not allow you to check the new ranges of input values which become accessible on 64-bit systems. Unit tests are originally developed in such a way that they can be passed in a short time. And the function which usually works with an array with the size of tens of Mb, will probably process tens of Kb in unit tests. It is justified for this function in tests may be called many times with different sets of input values. But suppose you have a 64-bit variant of the program. And now the function we study is processing more than 4 Gb of data. Surely there appears a necessity to raise the input size of an array in the tests either up to sizes more than 4 Gb. The problem is that the time of passing the tests will increase greatly in such a case.
That's why while modifying the sets of tests keep in mind the compromise between speed of passing unit tests and the fullness of the checks. Fortunately, there are other methods which can help you to make sure of the efficiency of your applications.
Code review.
Code review is the best method of searching errors and improving code. Combined thorough code review may help to get rid of the errors in the program completely which are related to the peculiarities of the development of 64-bit applications. Of course, in the beginning one should learn which errors exactly one should search, otherwise the review won't give good results. For this purpose it is necessary to read this and other articles devoted to the port of programs from 32-bit systems on 64-bit ones, in time. Some interesting links concerning this topic can be found in the end of the article.
But this approach to the analysis of the original code has on significant disadvantage. It demands a lot of time and because of this it is actually inapplicable on large projects.
The compromise is the use of static analyzers. A static analyzer can be considered to be an automated system for code review where a fetch of potentially dangerous places is created for a programmer so that he could carry out the further analysis.
But in any case it is desirable to provide several code reviews for combined teaching the team to search for new kinds of errors occurring on 64-bit systems.
Built-in means of compilers.
Compilers allow to solve some problems of searching defect code. They often have built-in different mechanisms for diagnosing errors observed. For example, in Microsoft Visual C++ 2005 the following keys may be useful: /Wp64, /Wall, and in SunStudio C++ key -xport64.
Unfortunately, the possibilities they provide are often not enough and you should not rely only on them. But in any case it is highly recommended to enable the corresponding options of a compiler for diagnosing errors in the 64-bit code.
Static analyzers.
Static analyzers are a fine means to improve quality and safety of the program code. The basic difficulty related to the use of static analyzers consists in the fact that they generate quite a lot false warning messages about potential errors. Programmers being lazy by nature use this argument to find some way not to correct the found errors. In Microsoft this problem is solved by including necessarily the found errors in the bug tracking system. Thus a programmer just cannot choose between the correction of the code and tries to avoid this.
We think that such strict rules are justified. The profit of the quality code covers the outlay of time for static analysis and corresponding code modification. This profit is achieved by means of simplifying the code support and reducing the time of debugging and testing.
Static analyzers may be successfully used for diagnosing many of the kinds of errors observed in the article.
The authors know 3 static analyzers which are supposed to have means of diagnosing errors related to the port of programs on 64-bit systems. We would like to warn you at once that we may be mistaken about the possibilities they have, moreover, these are developing products and new versions may have great efficiency.
If you read these lines we are glad that you're interested. We hope the article has been useful for you and will help to simplify the development and debugging of 64-bit applications. We will be glad to receive your opinions, remarks, corrections, additions and will surely include them in the next version of the article. The more we'll describe typical errors the more profitable will be the use of our experience and getting help.
Re: Typical errors of porting C++ code on the 64-bit platform
Surely this article is very useful. But it has become a bit obsolete
by now and has some inaccuracies. To get a more detailed description
of 64-bit errors, please see the lessons on development of 64-bit
|All times are GMT +5.5. The time now is 00:30.


text:
Paige Brach, of Belle Mead, has been named to Alvernia University's Dean's List for the spring 2013 semester as a Junior Behavioral Health major at Alvernia and a graduate of Montgomery High School.
Boston University awarded academic degrees to 6,073 students in May 2013.
Among the graduates was Alexander J. Norcia, of Martinsville, who received a Bachelor of Arts in English, Magna Cum Laude, and a Bachelor of Science in Film and
Television, Summa Cum Laude.
The following students were named to the Spring 2013 Dean's List at Wake Forest University.
William Baker from Skillman
Christopher Caliguire from Skillman
Alison Caliguire from Skillman
Robert Chick from Skillman
Matthew Chinn from Skillman
Hannah Coffin from Somerville
Kevin Fischer from Warren
Angela Gallagher from Skillman
Nicole Gaziano from Basking Ridge
Michael Haderer from Belle Mead
Grace Hartley from Bernardsville
Sampson Ho from Watchung
Elizabeth Hughes from Warren
Alexander Mole from Bedminster
Ji Hae Moon from Belle Mead
Eileen Roach from Warren
Priyanka Surapaneni from Skillman
Andy Zhang from Belle Mead

subset: commoncrawl


text:
Nick Lidstrom is the genuine article. He is who you think he is, and who you hope he is.
My other buddy, the Bloomfiled Hills detective, has a kid that grew up playing Little Ceasar's with Dean Chelios. He would patrol by Cheli's Bloomfield Hills house to check on things for him, as the family would often be out of town at one of their other homes in Chicago or Malibu. Cheli even brought my buddie's kid to his hockey camp in Chicago for free and let he and his kid stay at his house there with Dean and the other kids and a bunch of the fathers. It was summer and everyone was playiing in the pool and eating Cheli's food, then CHeli would leave for a workout while everyone was having fun at his house.
Edited by T.Low, 27 May 2010 - 02:43 PM.


text:
Helly Hansen Symphony S/S Shirt
Retailers' Descriptions
Here's what other sites are saying:
Free Shipping. Helly Hansen Women's Symphony SS Shirt DECENT FEATURES of the Helly Hansen Women's Symphony Short Sleeve Shirt Quick dry fabric Polyamide Elastane UPF 30+ Button front Regular fit HH Outline logo on chest Button sleeves Contrast neck band The SPECS Regular fit 92% Polyamide, 8% Elastane This product can only be shipped within the United States. Please don't hate us.
- Moosejaw
Helly Hansen Symphony S/S Shirt
previously retailed for:
The Helly Hansen Symphony S/S Shirt is not available from the stores we monitor. It was last seen June 7, 2013 at Moosejaw.
If you're looking for a new hiking shirt, check out the best reviewed current models.


text:
Selling Sustainability - full report
12 June 2012
Selling Sustainability? In search of the retail business case for sustainable diets.
WWF-UK is working with government, retailers and producers to understand and reduce the impacts of food consumption on the environment; here, we focus on the role of retailers. Working with Brook Lyndhurst we explore the retail business case for promoting sustainable diets, and present key recommendations that would enable retailers to play their part.
Selling Sustainability - reportblog comments powered by Disqus


text:
At some point in every conversation I had with Brian Sheridan prior to the start of the season the Union coach would gush about the prodigious talent of freshman Jamauri Bogan, then ask me to keep those comments off the record. He didn't want to hype his star-in-waiting too early for fear of putting too much pressure on him.
Bogan thrust himself into the spotlight last weekend with a four-touchdown effort in a 48-31 loss to No. 9 Immaculata. Bogan scored on a 13-yard run, a 51-yard pass and kick returns of 93 and 95 yards.
Bogan gave no hint of the fireworks to come when he bobbled the first kickoff in his direction and returned it all of six yards, then bobbled the second as well before returning it 93 yards to paydirt.
I try to avoid making eye contact with coaches from my privileged position on the sidelines but when Sheridan and I connected briefly during the forth quarter he shook his head and said, "that's a freshman. A freshman!"
The strongest testimonial I got on Bogan's behalf came from Immaculata star Ish Mack, who also had four touchdowns on the evening. Mack is always a good interview but when I asked him about Bogan he smiled broadly and got animated while giving this response:
"He's a phenomenal player. He's fast, and once he gets to the outside, no one's catching him. He's going to be really good."
Bogan's performance moved him into second place in the Union County scoring race.
Another underclassman who had a breakout performance last weekend was Dayton sophomore Anthony Cioffi, who outdid Bogan by scoring five touchdowns in a 39-12 triumph over Brearley on Saturday. Cioffi's touchdown came on runs of 75, 62, 35, 3 and 80 yards as he ran for 301 yards on 14 carries.
Cioffi celebrerated his effort Sunday by hosting a couple of friends who play for Brearley at his house, where they revealed their game plan of trying to contain him from running or pitching to the outside. Instead, Cioffi cut upfield to rather spectacular results.
Senior A.J. Murray of Westfield ran for four first-half touchdowns in a 35-14 victory over Watchung Hills on Friday. Murray leads Union County with eight touchdowns and 48 points.
A.J. Murray, Westfield 8 0 48
Jamauri Bogan, Union 7 0 42
Anthiony Cioffi, Dayton 6 2 38
Elijah Hughes, Elizabeth 5 0 30
Joe Papandrea, Cranford 5 0 30
Clinton Coffey, Roselle 4 2 26
Devante Boles, Elizabeth 4 0 24
Jack Cole, New Providence 4 0 24
Robby Fay, New Providence 0 24 24
P.J. Franciotti, Johnson 4 0 24
Vinny Fuschetto, New Prov. 4 0 24
A.J. Iarussi, Summit 4 0 24
William Ingram, Linden 4 0 24
Andrew Romeo, Gov. Liv. 4 0 24
Davonte Ginyard, Hillside 2 8 20
FGs: Robby Fay, New Providence, 5; Mike Badgley, Summit, 2; Robert Gaeta, Cranford, 1.


text:
Khoe, W;
Freeman, E;
Woldorff, MG;
Mangun, GR;
Interactions between attention and perceptual grouping in human visual cortex.
, 1078
pp. 101-111.
Freeman et al. (Freeman, E., Sagi, D., Driver, J., 2001. Lateral interactions between targets and flankers in low-level vision depend on attention to the flankers. Nat. Neurosci. 4, 1032-1036) demonstrated that detection sensitivity for a low contrast Gabor stimulus improved in the presence of flanking, collinearly oriented grating stimuli, but only when observers attended to them. By recording visual event-related potentials (ERPs) elicited by a Gabor stimulus, we investigated whether this contextual cueing effect involves changes in the short-latency afferent visual signal from V1 that have a stimulus onset latency between 60 and 80 ms and/or longer-latency changes from visual cortex Under dual-task conditions, the subjects performed contrast discrimination for a central Gabor and an orientation judgment for a pre-specified subset of the flanking Gabors. On random trials, the central Gabor could be collinearly or orthogonally oriented with respect to the attended flankers. Subjects showed improvements in discriminating the contrast of the central grating when it was oriented collinearly with the attended flankers The ERP difference between attending to collinear versus orthogonal flankers manifested as a positive polarity response at occipital electrodes with a latency of 180250 ms after stimulus onset. No shorter-latency contextual cueing differences were observed in the ERPs. The ERP latency profile of the contextual cueing effect argues against the hypothesis that short-latency afferent activity from V1 is the stage of processing at which attention can influence neuronal lateral interactions. However, the scalp voltage distribution of the longer-latency contextual cueing effect is similar to the one generated by the early phasic stimulus onset activity from V1. These findings leave open the possibility that V1 is involved in the attentional modulation of lateral interactions but that this has a longer time course, likely being mediated by re-afferent inputs from later stages of the visual pathway. (c) 2005 Elsevier B.V. All rights reserved.
|Interactions between attention and perceptual grouping in human visual cortex
|attention, ERPs, lateral interaction, striate cortex, extrastnate cortex, CAT STRIATE CORTEX, OBJECT-BASED ATTENTION, LATERAL INTERACTIONS, SPATIAL ATTENTION, CORTICAL AREAS, ALERT MONKEYS, FACILITATION, RESPONSES, STIMULI, NEURONS
|UCL classification:
|UCL > School of Life and Medical Sciences
UCL > School of Life and Medical Sciences > Faculty of Brain Sciences
UCL > School of Life and Medical Sciences > Faculty of Life Sciences
Archive Staff Only
|View Item